OTRS Archives - Ronaldo Richieri
Category Archives: OTRS
(Português) O impacto que gerei, com o opensource
Olá! Passando aqui no meu blog, para compartilhar um post que fiz no Facebok, após uma visita ao Senado Federal em Julho de 2018:
Nos últimos dois dias realizei um trabalho para área de TI do Senado Federal. Não tinha noção, mas no universo da TI que navego, sou conhecido como "Richieri" (E eu sempre achei que Richieri ou "Richieri do Acordeon" nunca seria um bom nome artístico, quem diria hahha).
Tenho um blog antigo onde compartilhei muito conhecimento e virei referência para um monte de gente e esse é o endereço (richieri.com) e por isso me conhecem assim.
Teve gente que abriu empresa seguindo meus passos e pedindo meus conselhos, teve gente que resolveu seus problemas corporativos lendo meus materiais, gente que ganhou muito dinheiro (ou ao menos economizou muito dinheiro) usando meus tutoriais, sem me dar nada em troca é claro, e isto é o opensource e está tudo certo =D. E lá no Senado, muitas pessoas queridas vieram me agradecer nos últimos dias pela dedicação que tive e tenho em compartilhar conhecimento, de forma aberta.
Teve até um rapaz veio me agradecer e disse que me usou de referência no TCC dele e isso é muito gratificante para mim 🙂 sou referência Acadêmica, logo eu, o cara da Aprendizagem Informal, quem diria hahahah. Confesso que isso não dá muito dinheiro, à s vezes até não dá dinheiro, mas quando você senta com uma Gestora de TI do Senado, que diz que o Senado adotou uma tecnologia opensource graças a um Webinar que você realizou há alguns anos atrás e aos materiais que publicou, bem, isso é bem gratificante!
Que bom que contribuí de forma espontânea e altruísta com muitas pessoas. Que bom que ajudei muitas empresas e ONGs. E que bom que ajudei muitos e muitos órgãos públicos municipais, estaduais e federais como prefeituras, tribunais, secretarias, ministérios, Câmara dos Deputados, Senado e órgãos militares a melhorarem seus processos de forma a atender melhor as pessoas e economizarem muiiiiito nosso dinheiro (algumas dezenas de milhões de reais), compartilhando conhecimento de forma voluntária. Bom este deve ter sido parte do meu "Seva" até agora 🙂
Gratidão!
This entry was posted in Aprendizagem Informal, OTRS, Software Livre, Open Source and Technology and tagged otrs on Thursday July 5th, 2018 by richieri.
Graphical Dashboards on OTRS – KPIs
We are working on Complemento with new graphical dashboards / KPIs. They are already available for the interesteds:
This entry was posted in OTRS, Software Livre and tagged dashboard, kpi, otrs on Tuesday October 29th, 2013 by richieri.
(Português) Workshop de OTRS no FISL 2013
Nesta quarta feira, 3 de Julho de 2013, apresentei o OTRS para pessoas do Governo, iniciativa privada, desenvolvedores e estudantes da PUC de Porto Alegre, juntamente com os camaradas Thiago Pacheco, Fabricio Pacheco e Leonardo Thietbohl Rodrigues, com quem formei a Complemento.
Para nós foi um grande prazer realizar esta apresentação e descobrir que nosso trabalho de anos de divulgação das soluções de software livre tem repercutido. Várias pessoas me agradeceram pessoalmente (inclusive um rapaz do Ministério das Comunicações), pelos módulos e artigos que sempre fiz questão de produzir e publicar na comunidade.
Recebemos também um convite da direção da Associação do Software Livre para participar de um jantar realizado para os palestrantes e ver um dos pais do software livre, Jon Maddog Hall, vestido de monge, com brincos e pirceings.
Mais uma pra recordar.
This entry was posted in OTRS, Software Livre and tagged asl, complemento, fisl, otrs, Software Livre on Wednesday July 10th, 2013 by richieri.
In last March (2012) we was part of the OTRS oficial certification process that occoured in São Paulo. As a result of this process, we have now a Portuguese area on OTRS Forum. Check it out:
One way of creating approval workflows with OTRS
Approval workflows can be created in different ways on OTRS.
There is a simple way to do that using ITSMIncidentProblemManagement.
With ITSMIncidentProblemManagement package, you get a Decision link on ticket menu. Obviously some configurations have to be done in order to this link be shown only for some users like a department manager (we will call this role decision makers now on). This also can be made in different ways.
I'd like to show a way to create those workflows. I made it this days and see to be efficient.
We have a group called Service Desk which watchs a queue called "ServiceDesk". This team receives and process all tickets on the system and try to solve them. They also send some tickets to approval when it's needed.
So we have to create a queue for each decision group. We may have decision makers on IT and decision makers on HR department for example.
We have those queues on the system:
Ask Approval
HR Decision Makers
Infraestructure specialist
When the ServiceDesk identifies a request which needs approval, they send it to the respective decision maker group.
The Decision Maker approves or not the ticket and he or she move it again to the service desk queue.
How to show Decision link only for decision makers?
Decision Makers will be registered on 2 groups: decisionit and decisionhr
Go to the SysConfig and access Ticket -> Frontend::Agent::Ticket::MenuModule
Find Ticket::Frontend::MenuModule###420-Decision and add a key called "Group" with this content: "rw:decisionit;rw:decisionhr".
To make the decision maker's life easier, I created a module (and a package) that moves the ticket to a "next defined queue", in the same screen where the approval is done. In our example, the ticket will be moved back to the ServiceDesk queue.
You can download this package here.
After it's installation, you may configure it on Sysconfig -> Ticket -> Frontend::Agent::Ticket::ViewDecisionMove
I think OTRS is a very flexible (and not high documented) tool. So, if you know another way to make decisions workflows, please share with us 🙂
This entry was posted in OTRS and tagged approval, aprovação, decisão, decision, itil, itsm, otrs, service desk, workflows on Wednesday February 8th, 2012 by richieri.
Single sign on between Joomla and OTRS Customer Interface
I have just developed my first version of a module called Kernel::System::CustomerAuth::JoomlaSSO
It allows Joomla logged users to access directly OTRS Customer interface (with automatic login) with no need to type user and pw again. OTRS Customer Backend should be the same as joomla for it to work.
Some customizetion are need on Joomla and OTRS side, so it's not a module yet.
If you are interested on it, contact me please.
This entry was posted in OTRS and tagged authentication, customer, customerauth, joomla, otrs, single sign on, sso on Thursday February 2nd, 2012 by richieri.
(Português) OTRS – Listas de Controle de Acessos (Access Control Lists ou ACL's)
As ACL's servem para incrementar o sistema de permissões do OTRS. Com elas é possível restringir escolhas de atributos do ticket ou ações possíveis de serem tomadas de acordo com as propriedades atuais do mesmo (fila atual, estado etc).
Atualmente criamos as ACLs com implementação de códigos no arquivo Kernel/Config.pm (recomendado) e não há interface gráfica para isso. Com sua utilização, é possível inclusive implementar pequenos workflows no sistema.
Vejamos um exemplo de ACL que restringe um chamado de prioridade alta (5) para que seja permitido move-lo apenas para uma fila chamada Alerta:
# ticket acl
$Self->{TicketAcl}->{'ACL-Nome-2'} = {
# match properties
# current ticket match properties
Queue => ['Raw'],
Priority => ['5 very high'],
# return possible options (white list)
# possible ticket options (white list)
Queue => ['Alerta'],
Neste exemplo, é bom que se deixe claro que a única ação que restringimos foi a alteração de fila. As outras ações continuam possíveis de acordo com as parametrizações e permissões do usuário. Por exemplo, ainda é possível adicionar notas ao chamado, responde-lo, mudar seu status para qualquer um disponível no sistema.
É possível notar que existem dois blocos de código neste exemplo acima. O  primeiro com comentário "# match properties" é a definição das propriedades atuais do ticket, como se fosse um filtro onde definimos em que ocasiões essa ACL será aplicada.
No segundo bloco definimos as restrições ou permissões que os tickets que "cairem" nesta ACL sofrerão.
Vamos aprimorar este exemplo fazendo com que um ticket de prioridade 5 não possa ser fechado na fila Raw através da tela "Fechar" (módulo AgenteTicketClose). Ficaria assim:
$Self->{TicketAcl}->{'ACL-Alerta5'} = {
AgentTicketClose => 0,
Além de restringir a escolha dos atributos dos tickets, podemos definir quais ações (ou telas) poderão ser exibidas ou não ao agente/cliente. Neste exemplo acima, além de permitir apenas que o agente mova este chamado para fila Alerta, também desabilitamos a tela e o botão "Fechar" (módulo AgenteTicketClose). Assim não encorajaremos o atendente a fechar os tickets de prioridade 5 na fila Raw.
PossibleNot
No entanto, o atendente da ainda pode encerrar o chamado se este estiver na fila Raw, pois não desabilitamos a escolha os estados "Fechado" com e sem exito, ou seja, ele não verá a tela fechar, mas pode fechar o chamado caso clique em "Chamada telefônica realizada" e escolha um dos estados fechado.
Vamos simular então uma ACL onde o atendente nunca poderá fechar um chamado se o mesmo estiver na fila Raw com prioridade 5. Ficaria assim:
PossibleNot => {
# possible not ticket options
State => ['closed successful','closed unsuccessful'],
Notem que adicionamos um terceiro bloco de código, o "PossibleNot". Ali definimos o que não será possível fazer. Para tentar esclarecer mais:
Properties: "Quais chamados ou situações". No nosso caso, todos os chamados que estiverem na fila Raw com prioridade 5 (Muito Alta)
Possible: "É possível apenas isto"! No nosso caso, em relação a mover chamados, restringimos para que seja apenas possível mover para a fila Alerta
PossibleNot: "Não é possível apenas isto, o resto pode"! No nosso caso, o atendente poderá escolher todos os estados disponíveis de ticket, menos "Fechado com sucesso" e "Fechado sem sucesso".
Também é possível utilizar expressões regulares. No exemplo abaixo (retirado da documentação oficial), exibimos apenas serviços que comecem com a palavra "Hardware", para um ticket estiver na fila HW ou uma de suas subfilas:
$Self->{TicketAcl}->{'Only-Hardware-Services-for-HW-Queues'} = {
# note we don't have "Ticket => {" because there's no ticket yet
Queue => {
Name => ['[RegExp]HW'],
# return possible options
# possible ticket options
Service => ['[RegExp]^(Hardware)'],
Vale a pena lembrar que os serviços começados com a palavra "Hardware" continuaram sendo exibidos em outras filas. Foi utilizando esse tipo de ACL que construí um módulo que permite escolher os serviços que queremos exibir em cada uma das filas do sistema.
Parâmetros possíveis
Aqui temos uma lista de todos os parâmetros possíveis para as ACLs:
$Self->{TicketAcl}->{'ACL-Name-Test'} = {
# current action match properties
Frontend => {
Action => ['AgentTicketPhone', 'AgentTicketEmail'],
# current user match properties
Group_rw => [
'hotline',
State => ['new', 'open'],
Priority => ['some priority'],
Lock => ['lock'],
CustomerID => ['some id'],
CustomerUserID => ['some id'],
TicketFreeKey1 => ['some key'],
TicketFreeKey2 => ['some key'],
TicketFreeKey8 => ['some key'],
TicketFreeText1 => ['some value'],
TicketFreeText2 => ['some value'],
TicketFreeText8 => ['some value'],
Queue => ['Hotline', 'Koordination'],
State => => ['some state'],
# possible action options (white list)
AgentTicketLock => 1,
AgentTicketZoom => 1,
AgentTicketClose => 1,
AgentTicketPending => 0,
AgentTicketNote => 1,
AgentTicketHistory => 0,
AgentTicketPriority => 1,
AgentTicketFreeText => 0,
AgentTicketHistory => 1,
AgentTicketCompose => 1,
AgentTicketBounce => 1,
AgentTicketTicketPrint => 0,
AgentTicketForward => 1,
AgentTicketTicketLink => 1,
AgentTicketPrint => 1,
AgentTicketPhone => 1,
AgentTicketCustomer => 1,
AgentTicketOwner => 0,
# remove options (black list)
# possible ticket options (black list)
State => ['closed', 'removed'],
Consulte também:
http://doc.otrs.org/3.0/en/html/acl.html
http://faq.otrs.org/otrs/public.pl?Action=PublicFAQ&ItemID=68
This entry was posted in OTRS and tagged acl, acls, otrs, ticket on Saturday January 7th, 2012 by richieri.
(Português) OTRS – Status (estados) pré definidos dos Tickets
Uma livre tradução do manul do OTRS 3.0:
http://doc.otrs.org/3.0/en/html/states.html
O OTRS permite alterar estados de bilhetes pré-definidos e os seus tipos, ou mesmo adicionar novos. Dois atributos são importantes para um estado: o nome do estado e do tipo de estado.
Os estados padrão do OTRS são: 'fechado com sucesso', 'fechado sem sucesso', 'merged', 'novo', 'aberto', 'pendente auto fechamento +', 'pendente auto fechamento -' 'lembrete de pendente', e 'removido' .
Os bilhetes estão neste estado geralmente quando são criados a partir de e-mails recebidos.
Comentário Ronaldo: Desta forma os atendentes sabem que este ticket ainda não foi lido, ou seja, nossa empresa ainda não tem conhecimento deste problema.
Este é o estado padrão de bilhetes atribuídos a filas e agentes.
Lembrete de pendente
Quando o tempo determinado no campo "Data de Pendência" for atingido, o dono bilhete/ticket receberá um email de lembrete sobre o bilhete. Se o bilhete não estiver bloqueado, o lembrete será enviado a todos os agentes da fila. Lembrete de bilhetes só serão enviados durante o horário comercial, e são repetidamente enviados a cada 24 horas até que o estado bilhete seja alterada pelo agente. Tempo gasto pelo bilhete neste estado continua a contar para fins de escalonamento.
Pendente auto fechamento –
Bilhetes neste status serão definidos como "Fechado sem sucesso" se o tempo de espera determinado em "Data de Pendência" for atingido. Tempo gasto pelo bilhete neste estado continua a contar para fins de escalonamento.
Pendente auto fechamento +
Bilhetes neste status serão definidos como "Fechado com sucesso" se o tempo de espera determinado em "Data de Pendência" for atingido. Tempo gasto pelo bilhete neste estado continua a contar para fins de escalonamento.
Este é o estado de bilhetes que foram fundidos com outros bilhetes.
Fechado com sucesso
Este é o estado final de bilhetes que foram resolvidos com êxito. Dependendo da configuração, você pode ou não ser capaz de reabrir bilhetes fechado.
Fechado sem sucesso
Este é o estado final de bilhetes que não foram resolvidos com êxito. Dependendo da configuração, você pode ou não ser capaz de reabrir bilhetes fechado.
This entry was posted in OTRS and tagged aberto, estados, fechado, novo, otrs, status on Thursday December 8th, 2011 by richieri.
Access OTRS with Android Mobile
Lot of people asked it:
https://otrsteam.ideascale.com/a/dtd/App-for-mobile-devices-like-Android–Blackberry/83263-10369
One guy or company made it!
https://market.android.com/details?id=com.ptitov.megaticket&rdid=com.ptitov.megaticket&rdot=1
This entry was posted in OTRS and tagged android, atrix, otrs on Thursday October 27th, 2011 by richieri.
OTRS: Show/Hide itens on Ticket Menu according to the user group
OTRS is a great software it's not 100% documentated. I find this tip digging the source code.
Imagine that you want to remove the Priority link from Nav Bar of Level 1 Agente Front end, while he/she is viewing a ticket and you want it to be viewable only for supervisors.
Go to ADMIN-> SysConfig -> Ticket -> Frontend::Agent::Ticket::MenuModule
Then find the parameter you want to hide/remove. In this case, Ticket::Frontend::MenuModule###300-Priority
Add a key called "Group" and the put "rw:group_that_has_access" as the content. To add more groups, separete with ";". For example: "rw:admin;rw;supervisors".
This entry was posted in OTRS and tagged otrs, permission, sysconfig, ticket menu bar on Friday October 14th, 2011 by richieri.