NexTool Solutions

Pedir que um gestor faça login no GLPI só para aprovar um chamado é atrito que custa horas de SLA. Quem opera service desk conhece a cena: o e-mail de aprovação chega, o gestor lê no celular, não tem a senha à mão e o chamado dorme até alguém cobrar por telefone.

O problema

Fluxos de aprovação, validação de solução e pesquisa de satisfação dependem da ação de quem quase nunca entra no GLPI: o gestor que autoriza uma compra, o cliente externo que confirma que o problema foi resolvido, o usuário final que avalia o atendimento. No GLPI nativo, todas essas ações acontecem dentro da interface autenticada. Para quem não tem conta - ou tem, mas não lembra a senha - isso vira uma barreira real.

O resultado é previsível: aprovações represadas, chamados parados esperando um retorno que nunca vem e a equipe gastando tempo em cobrança manual. A pesquisa de satisfação é o caso extremo: a taxa de resposta fica perto de zero quando exige login, porque o usuário simplesmente abandona na tela de autenticação. Não é falta de vontade de responder; é uma etapa a mais que ninguém quer vencer.

Como funciona

O módulo Mail Interactions do NexTool adiciona tags de notificação ao GLPI. No momento em que o e-mail é enfileirado, o módulo troca cada tag por uma URL única e efêmera. O destinatário clica, cai em uma página pública, confirma a ação, e o GLPI é atualizado - sem tela de login, sem conta.

• Aprovar ou recusar validações - as tags ##ticket.approve_link## e ##ticket.reject_link## entram no modelo de notificação de validação. O aprovador abre o link, opcionalmente escreve uma justificativa e confirma.
• Validar ou reabrir a solução - ##ticket.validate_link## fecha o chamado quando o solicitante confirma que resolveu; ##ticket.reopen_link## reabre para novo atendimento.
• Pesquisa de satisfação em um clique - ##ticket.satisfaction_link_1## até ##ticket.satisfaction_link_10## já carregam a nota pré-selecionada; o usuário clica na nota direto no e-mail e, se quiser, deixa um comentário.
• Chamados, Mudanças e Problemas - as mesmas tags existem por tipo de item: ##ticket.*##, ##change.*## e ##problem.*## (em Problema, apenas validar e reabrir).
• Tokens de uso único e com prazo - cada link vale por um período configurável (padrão 7 dias) e é invalidado no primeiro uso, impedindo cliques repetidos ou reaproveitamento.
• Justificativa obrigatória, quando fizer sentido - dá para exigir comentário na recusa, na reabertura ou em notas de satisfação abaixo de um limite, elevando a qualidade do registro.

Módulo vs. GLPI nativo

O que muda na prática, comparando com o comportamento padrão do GLPI:

Exemplo real: as tags no modelo de notificação

As tags entram no corpo HTML do modelo de notificação de validação (Configuração > Notificações > Modelos de notificação). Um trecho típico do corpo:

<!-- Modelo: evento "Validação de chamado" -->
<p>Olá ##validation.validator##,</p>
<p>O chamado <strong>##ticket.title##</strong> (##ticket.id##)
   aguarda a sua aprovação.</p>

<p style="text-align:center">
  <a href="##ticket.approve_link##"
     style="background:#22c55e;color:#fff;padding:12px 20px;border-radius:6px">
     Aprovar
  </a>
  <a href="##ticket.reject_link##"
     style="background:#ef4444;color:#fff;padding:12px 20px;border-radius:6px">
     Recusar
  </a>
</p>

<p>Os links expiram em 7 dias e só podem ser usados uma vez.</p>

Quando o e-mail é gerado, o Mail Interactions substitui cada tag por uma URL tokenizada. Só a título de ilustração, o formato é este:

https://suporte.suaempresa.com/plugins/nextool/ajax/module_ajax.php
    ?module=mailinteractions&file=approve.php
    &token=Yc7d...token-opaco-de-256-bits...&a=approve

O token não codifica nada do chamado: é um valor aleatório que só existe porque foi emitido e salvo no servidor. Não há como forjar, adivinhar ou reutilizar. Os principais ajustes ficam na aba Configurar do módulo:

# Configuração > NexTool > Módulos > Mail Interactions > Configurar
token_ttl_days                     = 7    # validade do link, em dias
force_https_links                  = 1    # sempre gerar URLs https://
require_reject_description         = 1    # exigir justificativa ao recusar
require_reopen_description         = 1    # exigir justificativa ao reabrir
satisfaction_max_stars             = 5    # escala da pesquisa (5 ou 10)
satisfaction_require_comment_below = 3    # exigir comentário se a nota < 3

O que aprendemos na sustentação

Operando GLPI para clientes, o erro mais comum que vemos não é técnico, é de configuração: colocar as tags de aprovação no modelo de notificação errado. Se você põe ##ticket.approve_link## em um modelo que também dispara em outros eventos (por exemplo "Chamado atualizado"), o link vai parar em e-mails onde não existe validação pendente - e o destinatário recebe um link que só leva a uma página de erro. O correto é usar essas tags apenas no modelo do evento de validação. É simples, mas responde por boa parte dos chamados de suporte que abrimos sobre "o link não funciona".

O segundo aprendizado veio de um detalhe de infraestrutura. Appliances de segurança de e-mail - Microsoft Safe Links, Mimecast e similares - pré-abrem os links das mensagens para escanear antes de o usuário clicar. Se a aprovação fosse executada no GET puro do link, esses robôs "aprovariam" o chamado sozinhos, gerando aprovações-fantasma. Por isso o módulo nunca age no clique: o link abre uma página de confirmação e a ação só é gravada em um POST com token de formulário próprio. O robô que faz o pre-fetch enxerga a página, mas não confirma o formulário, então o token de uso único continua intacto. Foi essa escolha de arquitetura que evitou aprovações indevidas em um cliente com Office 365 corporativo - um problema que só aparece em produção, nunca no ambiente de teste.

Um detalhe fino que vale ligar: na validação de solução, quando a entidade tem um prazo de fechamento configurado (o solvedelay do GLPI), o módulo usa esse prazo como validade do link, em vez do padrão de 7 dias. Assim o link vive exatamente enquanto o chamado ainda pode ser reaberto - nem mais, nem menos.

Como ativar

1. Tenha o plugin NexTool instalado no seu GLPI 10 ou 11.
2. Acesse Configuração > NexTool > Módulos.
3. Ative o Mail Interactions e clique em Configurar para definir a validade do token, o HTTPS forçado e as regras de justificativa.
4. Em Configuração > Notificações > Modelos de notificação, edite o modelo do evento de validação (ou de solução/satisfação) e inclua as tags desejadas no corpo.
5. Dispare uma validação de teste e confira o e-mail: os links devem apontar para /plugins/nextool/ajax/module_ajax.php com um token na URL.

Para quem é indicado - e quando não usar

O Mail Interactions é indicado para qualquer organização que use fluxos de aprovação no GLPI e sofra com lentidão porque os aprovadores não acessam o sistema com frequência. É especialmente valioso para service desks que atendem usuários finais e clientes externos sem conta no GLPI - eles validam soluções e respondem pesquisas sem nenhuma barreira de acesso.

Quando não usar: se a sua política de segurança exige que toda aprovação seja rastreada por login autenticado e MFA (compliance financeiro, aprovações de alto valor), a página pública não substitui esse controle - nesse caso, mantenha a aprovação dentro da sessão autenticada do GLPI. O módulo resolve atrito, não é um substituto de assinatura eletrônica com valor jurídico.

Compatibilidade

• GLPI: 10.0+ e 11.0+
• Plugin: NexTool (módulo Mail Interactions, base 4.3.4 ou superior)
• Itens suportados: Chamado, Mudança e Problema (Problema apenas validar/reabrir)
• Plano: sob demanda

Próximo passo

O Mail Interactions faz parte do NexTool, ecossistema de módulos para expandir o GLPI sem customização de código. Fale com a equipe para uma demonstração no seu ambiente.

Este conteúdo foi produzido com auxílio de inteligência artificial e revisado pela equipe Nextool Solutions.