Os tickets duplicados nascem de um detalhe simples: quando alguém responde "a todos" num tópico de suporte, o coletor de e-mail do GLPI não reconhece a mensagem como parte da conversa e abre um ticket novo. O módulo Mail Analyzer interceta essa mensagem antes da criação do ticket e decide, pelos cabeçalhos do próprio e-mail, se é um ticket novo ou apenas um seguimento do original.
O problema: o coletor nativo perde o tópico
O coletor de e-mail do GLPI associa uma resposta ao ticket original lendo o marcador que ele mesmo insere no assunto das notificações, no formato [GLPI #0000123]. Enquanto esse marcador sobrevive na resposta, tudo funciona: a mensagem torna-se um seguimento do ticket certo. O problema aparece quando o marcador se perde.
O cenário clássico é o "Responder a todos". Um cliente abre o ticket e coloca o gestor em cópia. O suporte responde, o gestor decide comentar e clica em "Responder a todos". O cliente de e-mail dele reescreve o assunto (RE:, Enc:), corta o marcador ou inicia uma mensagem nova a partir do histórico - e o GLPI, sem encontrar o [GLPI #...], abre um segundo ticket para a mesma conversa.
O resultado é conhecido por quem opera um service desk: dois ou mais tickets para o mesmo assunto, histórico fragmentado, o risco de dois analistas trabalharem em paralelo sem saber e um SLA distorcido, porque cada duplicado conta como um novo pedido. Em ambientes empresariais, onde colocar os gestores em cópia do tópico é cultura, isto torna-se dezenas de duplicados por semana.
Como o Mail Analyzer funciona
O módulo atua através de hooks no ciclo de vida do ticket, intercetando o e-mail já recolhido antes de se tornar um ticket. Em vez de depender só do marcador do assunto, lê os cabeçalhos padrão de e-mail (RFC 5322) e aplica uma decisão hierárquica em três estratégias:
- Análise de References - verifica se o e-mail cita um
Message-IDgerado pelo próprio GLPI (formatoGLPI_*). Se cita, é uma resposta legítima ao ticket e torna-se um seguimento. - Análise de In-Reply-To - se o
In-Reply-Toaponta para o e-mail de um terceiro já registado pelo módulo, e não para umMessage-IDdo GLPI, a mensagem é identificada como cadeia de cópia e bloqueada. - Verificação do primeiro e-mail - o recurso alternativo: se o ticket ainda não tem nenhum e-mail registado, essa mensagem é tratada como o original e permitida.
Sobre essa base, três ajustes controlam o comportamento em ambientes reais:
- Thread-Index - melhora a deteção de cadeias em ambientes Microsoft (Outlook/Exchange), que usam esse cabeçalho próprio além do
In-Reply-To. - Block Chain Emails - um modo mais agressivo que bloqueia ativamente as respostas de terceiros em cópia. Indicado para operações de alto volume, com parcimónia.
- Modelo de notificação - quando um e-mail é bloqueado, o remetente recebe um aviso configurável a explicar o motivo, preservando a transparência.
Os cabeçalhos que decidem
Na prática, a diferença entre um seguimento e um duplicado está em duas linhas do cabeçalho. O exemplo abaixo mostra os dois casos lado a lado:
# Resposta legitima ao ticket: o cabecalho References cita o Message-ID do GLPI (GLPI_*)
# --> Mail Analyzer trata como SEGUIMENTO do ticket original
Subject: [GLPI #0004521] Impressora do financeiro sem toner
Message-ID: <a1b2c3@mail.cliente.com>
In-Reply-To: <GLPI_7f3a9@suporte.empresa.com>
References: <GLPI_7f3a9@suporte.empresa.com>
# Um terceiro em copia clicou em "Responder a todos":
# In-Reply-To aponta para o e-mail de OUTRO utilizador, nao para um Message-ID do GLPI
# --> Mail Analyzer BLOQUEIA a criacao de um ticket duplicado
Subject: RE: Impressora do financeiro sem toner
Message-ID: <d4e5f6@mail.gestor.com>
In-Reply-To: <a1b2c3@mail.cliente.com>
References: <a1b2c3@mail.cliente.com>Funcionalidade do módulo vs comportamento nativo
| Situação | Coletor nativo do GLPI | Com o Mail Analyzer |
|---|---|---|
| A resposta mantém o marcador [GLPI #id] no assunto | Torna-se um seguimento do ticket | Torna-se um seguimento do ticket |
| Um terceiro em cópia responde "a todos" e o assunto é reescrito | Abre um ticket novo (duplicado) | Reconhece a cadeia por References/In-Reply-To e não duplica |
| Ambiente Exchange que agrupa por Thread-Index | Depende só do assunto e do In-Reply-To | Usa também o Thread-Index para ligar a conversa |
| E-mail bloqueado por ser de cadeia de cópia | Não aplicável | O remetente recebe uma notificação configurável |
| Primeiro e-mail de um assunto novo | Abre ticket | Reconhece-o como o original e permite a abertura |
Como ativar
- Instale o plugin NexTool no GLPI e confirme que a recolha de e-mail (recetores) já está a funcionar.
- Aceda a Configuração > NexTool > Módulos.
- Ative o módulo Mail Analyzer.
- Ajuste o Thread-Index e o Block Chain Emails conforme o perfil do ambiente.
- Defina o modelo de notificação para os e-mails bloqueados.
O que aprendemos na sustentação
Na sustentação de coletores de e-mail em clientes, o erro que mais gera duplicados não é um tecnicismo do GLPI, é comportamental: o gestor em cópia responde do telemóvel, a aplicação reescreve o assunto e o marcador desaparece. Antes do Mail Analyzer, a "correção" era pedir às pessoas para não editarem o assunto, o que nunca funciona. Passámos a resolver na origem, lendo References e In-Reply-To, que o cliente de e-mail preserva mesmo quando mexe no assunto. O detalhe que só aparece a operar: em ambientes Exchange, ativar o Thread-Index faz uma diferença real, porque o Outlook agrupa a conversa por esse cabeçalho e nem sempre mantém um In-Reply-To limpo. E uma recomendação de campo: ative o Block Chain Emails de forma gradual e sempre com o modelo de notificação configurado, senão um e-mail legítimo de um terceiro é bloqueado em silêncio e ninguém repara até o cliente reclamar.
Para quem é indicado (e quando não usar)
O Mail Analyzer é indicado para qualquer service desk que abre tickets por recolha de e-mail e opera em ambiente empresarial, em especial:
- Empresas onde gestores e responsáveis são rotineiramente colocados em cópia dos tópicos de suporte;
- Operações com alta rotatividade de analistas, em que os duplicados passam despercebidos;
- MSP que atendem vários clientes e precisam de um histórico organizado por empresa;
- Equipas que dependem de um histórico consolidado para auditoria e conformidade.
Não faz sentido ativar se não usa recolha de e-mail: se os tickets entram só pelo catálogo de serviços ou por formulário, não há mensagem para intercetar. E convém ter cuidado com o Block Chain Emails em operações pequenas, onde o duplicado é raro, porque o modo agressivo pode bloquear um e-mail de um terceiro que deveria, de facto, tornar-se um ticket novo.
Compatibilidade
- GLPI: 10.x e 11.x
- Plano: FREE
- Plugin: NexTool 3.x ou superior
- PHP: 8.0+
O Mail Analyzer faz parte do NexTool, plugin modular para GLPI. Para ver o módulo no seu cenário de recolha de e-mail, fale com a equipa.
Este conteúdo foi produzido com o apoio de inteligência artificial e revisto pela equipa Nextool Solutions.
