NexTool Solutions

Pedir a um gestor que inicie sessão no GLPI só para aprovar um pedido é atrito que custa horas de SLA. Quem opera um service desk conhece a cena: o e-mail de aprovação chega, o gestor lê no telemóvel, não tem a palavra-passe à mão e o pedido adormece até alguém insistir por telefone.

O problema

Os fluxos de aprovação, a validação de solução e os inquéritos 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 ficou resolvido, o utilizador final que avalia o atendimento. No GLPI nativo, todas estas ações acontecem dentro da interface autenticada. Para quem não tem conta - ou tem, mas não se lembra da palavra-passe - isto torna-se uma barreira real.

O resultado é previsível: aprovações represadas, pedidos parados à espera de uma resposta que nunca chega e a equipa a gastar tempo em insistência manual. O inquérito de satisfação é o caso extremo: a taxa de resposta fica perto de zero quando exige início de sessão, porque o utilizador simplesmente desiste no ecrã de autenticação. Não é falta de vontade de responder; é mais um passo que ninguém quer vencer.

Como funciona

O módulo Mail Interactions do NexTool acrescenta etiquetas de notificação ao GLPI. No momento em que o e-mail é colocado em fila, o módulo troca cada etiqueta por um URL único e efémero. O destinatário clica, chega a uma página pública, confirma a ação, e o GLPI é atualizado - sem ecrã de início de sessão, sem conta.

• Aprovar ou recusar validações - as etiquetas ##ticket.approve_link## e ##ticket.reject_link## entram no modelo de notificação de validação. O aprovador abre o link, opcionalmente escreve uma justificação e confirma.
• Validar ou reabrir a solução - ##ticket.validate_link## fecha o pedido quando o requerente confirma que ficou resolvido; ##ticket.reopen_link## reabre-o para novo atendimento.
• Inquérito de satisfação num clique - de ##ticket.satisfaction_link_1## a ##ticket.satisfaction_link_10## já levam a nota pré-selecionada; o utilizador clica na nota diretamente no e-mail e, se quiser, deixa um comentário.
• Pedidos, Alterações e Problemas - as mesmas etiquetas existem por tipo de item: ##ticket.*##, ##change.*## e ##problem.*## (em Problema, apenas validar e reabrir).
• Tokens de uso único e com prazo - cada link é válido por um período configurável (7 dias por omissão) e é invalidado no primeiro uso, impedindo cliques repetidos ou reutilização.
• Justificação obrigatória, quando faz sentido - é possível exigir comentário na recusa, na reabertura ou em notas de satisfação abaixo de um limite, elevando a qualidade do registo.

Módulo vs. GLPI nativo

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

Um exemplo real: as etiquetas no modelo de notificação

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

<!-- Modelo: evento "Validação de pedido" -->
<p>Olá ##validation.validator##,</p>
<p>O pedido <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 etiqueta por um URL tokenizado. Apenas 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 pedido: é um valor aleatório que só existe porque foi emitido e guardado no servidor. Não há forma de o forjar, adivinhar ou reutilizar. Os principais ajustes ficam no separador 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    # gerar sempre URLs https://
require_reject_description         = 1    # exigir justificação ao recusar
require_reopen_description         = 1    # exigir justificação ao reabrir
satisfaction_max_stars             = 5    # escala do inquérito (5 ou 10)
satisfaction_require_comment_below = 3    # exigir comentário se a nota < 3

O que aprendemos na sustentação

A operar GLPI para clientes, o erro mais comum que vemos não é técnico, é de configuração: colocar as etiquetas de aprovação no modelo de notificação errado. Se puser ##ticket.approve_link## num modelo que também dispara noutros eventos (por exemplo "Pedido atualizado"), o link vai parar a 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 etiquetas apenas no modelo do evento de validação. É simples, mas responde por boa parte do suporte que abrimos sobre "o link não funciona".

A segunda lição veio de um detalhe de infraestrutura. As appliances de segurança de e-mail - Microsoft Safe Links, Mimecast e semelhantes - pré-abrem os links das mensagens para os analisar antes de o utilizador clicar. Se a aprovação fosse executada no GET puro do link, esses robôs "aprovariam" o pedido 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 num POST com token de formulário próprio. O robô que faz o pre-fetch vê a página, mas não confirma o formulário, por isso o token de uso único fica intacto. Foi esta escolha de arquitetura que evitou aprovações indevidas num cliente com Office 365 empresarial - um problema que só aparece em produção, nunca no ambiente de teste.

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

Como ativar

1. Tenha o plugin NexTool instalado no seu GLPI 10 ou 11.
2. Aceda a 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 justificação.
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 etiquetas pretendidas no corpo.
5. Dispare uma validação de teste e verifique o e-mail: os links devem apontar para /plugins/nextool/ajax/module_ajax.php com um token no 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 acedem ao sistema com frequência. É especialmente valioso para service desks que atendem utilizadores finais e clientes externos sem conta no GLPI - validam soluções e respondem a inquéritos sem qualquer barreira de acesso.

Quando não usar: se a sua política de segurança exige que toda a aprovação seja rastreada por um início de sessão autenticado com MFA (conformidade financeira, aprovações de valor elevado), a página pública não substitui esse controlo - 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: Pedido, Alteração e Problema (Problema: apenas validar/reabrir)
• Plano: a pedido

Próximo passo

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

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