Chiedere a un responsabile di accedere a GLPI solo per approvare un ticket è un attrito che costa ore di SLA. Chi gestisce un service desk conosce la scena: arriva l'e-mail di approvazione, il responsabile la legge sul telefono, non ha la password a portata di mano e il ticket dorme finché qualcuno non lo sollecita per telefono.
Il problema
I flussi di approvazione, la validazione della soluzione e i sondaggi di soddisfazione dipendono da un'azione di chi quasi mai entra in GLPI: il responsabile che autorizza un acquisto, il cliente esterno che conferma che il problema è risolto, l'utente finale che valuta il servizio. In GLPI nativo, tutte queste azioni avvengono all'interno dell'interfaccia autenticata. Per chi non ha un account - o ce l'ha ma non ricorda la password - questo diventa una barriera reale.
Il risultato è prevedibile: approvazioni bloccate, ticket fermi in attesa di una risposta che non arriva mai, e il team che perde tempo in solleciti manuali. Il sondaggio di soddisfazione è il caso estremo: il tasso di risposta scende vicino allo zero quando richiede il login, perché l'utente semplicemente abbandona alla schermata di autenticazione. Non è mancanza di volontà di rispondere; è un passaggio in più che nessuno vuole affrontare.
Come funziona
Il modulo Mail Interactions di NexTool aggiunge tag di notifica a GLPI. Nel momento in cui l'e-mail viene messa in coda, il modulo sostituisce ogni tag con una URL unica ed effimera. Il destinatario clicca, arriva su una pagina pubblica, conferma l'azione e GLPI viene aggiornato - senza schermata di login, senza account.
- Approvare o rifiutare validazioni - i tag
##ticket.approve_link##e##ticket.reject_link##vanno nel modello di notifica di validazione. L'approvatore apre il link, eventualmente scrive una motivazione e conferma. - Validare o riaprire la soluzione -
##ticket.validate_link##chiude il ticket quando il richiedente conferma che è risolto;##ticket.reopen_link##lo riapre per una nuova gestione. - Sondaggio di soddisfazione in un clic - da
##ticket.satisfaction_link_1##a##ticket.satisfaction_link_10##portano già il voto preselezionato; l'utente clicca sul punteggio direttamente dall'e-mail e, se vuole, lascia un commento. - Ticket, Modifiche e Problemi - gli stessi tag esistono per tipo di elemento:
##ticket.*##,##change.*##e##problem.*##(per Problema, solo validare e riaprire). - Token monouso e a tempo - ogni link è valido per un periodo configurabile (7 giorni di default) e viene invalidato al primo uso, impedendo clic ripetuti o riutilizzo.
- Motivazione obbligatoria, quando ha senso - si può richiedere un commento al rifiuto, alla riapertura o sui voti di soddisfazione sotto una soglia, migliorando la qualità del registro.
Modulo vs. GLPI nativo
Cosa cambia in pratica, rispetto al comportamento standard di GLPI:
| Azione | GLPI nativo | Con Mail Interactions |
|---|---|---|
| Approvare / rifiutare validazione | L'approvatore deve accedere e aprire il ticket | Un clic sul link dell'e-mail, conferma sulla pagina pubblica |
| Confermare / riaprire soluzione | Il richiedente agisce nell'interfaccia autenticata | Link diretto nell'e-mail di soluzione proposta |
| Sondaggio di soddisfazione | Risposto nell'interfaccia o nel portale GLPI | Voto preselezionato, risposta in un clic |
| Utente senza account GLPI | Non può agire | Agisce dalla pagina pubblica, senza consumare un utente |
| Sicurezza del link | Sessione GLPI autenticata | Token da 256 bit monouso, con scadenza e HTTPS |
Un esempio reale: i tag nel modello di notifica
I tag vanno nel corpo HTML del modello di notifica di validazione (Configurazione > Notifiche > Modelli di notifica). Un estratto tipico del corpo:
<!-- Modello: evento "Validazione ticket" -->
<p>Ciao ##validation.validator##,</p>
<p>Il ticket <strong>##ticket.title##</strong> (##ticket.id##)
attende la tua approvazione.</p>
<p style="text-align:center">
<a href="##ticket.approve_link##"
style="background:#22c55e;color:#fff;padding:12px 20px;border-radius:6px">
Approva
</a>
<a href="##ticket.reject_link##"
style="background:#ef4444;color:#fff;padding:12px 20px;border-radius:6px">
Rifiuta
</a>
</p>
<p>I link scadono tra 7 giorni e possono essere usati una sola volta.</p>Quando l'e-mail viene generata, Mail Interactions sostituisce ogni tag con una URL tokenizzata. Solo a titolo illustrativo, il formato è questo:
https://supporto.tuaazienda.com/plugins/nextool/ajax/module_ajax.php
?module=mailinteractions&file=approve.php
&token=Yc7d...token-opaco-da-256-bit...&a=approveIl token non codifica nulla del ticket: è un valore casuale che esiste solo perché è stato emesso e salvato sul server. Non c'è modo di falsificarlo, indovinarlo o riutilizzarlo. Le impostazioni principali sono nella scheda Configura del modulo:
# Configurazione > NexTool > Moduli > Mail Interactions > Configura
token_ttl_days = 7 # validità del link, in giorni
force_https_links = 1 # generare sempre URL https://
require_reject_description = 1 # richiedere una motivazione al rifiuto
require_reopen_description = 1 # richiedere una motivazione alla riapertura
satisfaction_max_stars = 5 # scala del sondaggio (5 o 10)
satisfaction_require_comment_below = 3 # richiedere un commento se il voto < 3Cosa abbiamo imparato in gestione
Gestendo GLPI per i clienti, l'errore più comune che vediamo non è tecnico, è di configurazione: mettere i tag di approvazione nel modello di notifica sbagliato. Se metti ##ticket.approve_link## in un modello che si attiva anche su altri eventi (per esempio "Ticket aggiornato"), il link finisce in e-mail dove non c'è alcuna validazione in sospeso - e il destinatario riceve un link che porta solo a una pagina di errore. La cosa corretta è usare quei tag solo nel modello dell'evento di validazione. È semplice, ma spiega buona parte del supporto che apriamo su "il link non funziona".
La seconda lezione è nata da un dettaglio di infrastruttura. Gli appliance di sicurezza e-mail - Microsoft Safe Links, Mimecast e simili - preaprono i link dei messaggi per analizzarli prima che l'utente clicchi. Se l'approvazione fosse eseguita sul GET puro del link, quei bot "approverebbero" il ticket da soli, generando approvazioni fantasma. Per questo il modulo non agisce mai al clic: il link apre una pagina di conferma e l'azione viene registrata solo su un POST con il proprio token di modulo. Il bot che fa il pre-fetch vede la pagina ma non conferma il form, quindi il token monouso resta intatto. È stata questa scelta architetturale a evitare approvazioni indebite presso un cliente con Office 365 aziendale - un problema che appare solo in produzione, mai nell'ambiente di test.
Un dettaglio fine da conoscere: nella validazione della soluzione, quando l'entità ha un tempo di chiusura configurato (il solvedelay di GLPI), il modulo usa quel tempo come validità del link, invece del valore predefinito di 7 giorni. Così il link vive esattamente finché il ticket può ancora essere riaperto - né più, né meno.
Come attivarlo
- Avere il plugin NexTool installato sul tuo GLPI 10 o 11.
- Vai su Configurazione > NexTool > Moduli.
- Attiva Mail Interactions e fai clic su Configura per definire la validità del token, l'HTTPS forzato e le regole di motivazione.
- In Configurazione > Notifiche > Modelli di notifica, modifica il modello dell'evento di validazione (o di soluzione/soddisfazione) e includi i tag desiderati nel corpo.
- Avvia una validazione di prova e controlla l'e-mail: i link devono puntare a
/plugins/nextool/ajax/module_ajax.phpcon un token nella URL.
Per chi è indicato - e quando non usarlo
Mail Interactions è adatto a qualsiasi organizzazione che usa flussi di approvazione in GLPI e soffre di lentezze perché gli approvatori accedono raramente al sistema. È particolarmente prezioso per i service desk che servono utenti finali e clienti esterni senza account GLPI - validano soluzioni e rispondono ai sondaggi senza alcuna barriera d'accesso.
Quando non usarlo: se la tua policy di sicurezza richiede che ogni approvazione sia tracciata tramite un login autenticato con MFA (conformità finanziaria, approvazioni ad alto valore), la pagina pubblica non sostituisce quel controllo - in tal caso, mantieni l'approvazione dentro la sessione autenticata di GLPI. Il modulo elimina l'attrito; non sostituisce una firma elettronica con valore legale.
Compatibilità
- GLPI: 10.0+ e 11.0+
- Plugin: NexTool (modulo Mail Interactions, base 4.3.4 o superiore)
- Elementi supportati: Ticket, Modifica e Problema (Problema: solo validare/riaprire)
- Piano: su richiesta
Prossimo passo
Mail Interactions fa parte di NexTool, un ecosistema di moduli per estendere GLPI senza personalizzazioni di codice. Parla con il team per una demo nel tuo ambiente.
Questo contenuto è stato prodotto con l'aiuto dell'intelligenza artificiale e revisionato dal team Nextool Solutions.
