Una variabile di automazione è ciò che separa un generico "Il tuo ticket è stato aggiornato" da un "Ticket 12345 - Stampante senza toner passato a In lavorazione, gestito dalla tecnica Ana Paula". In GLPI queste variabili sono i tag di notifica: marcatori ##...## che il motore sostituisce con il dato reale al momento dell'invio. Sembrano banali finché arriva il giorno in cui il nome del richiedente esce vuoto nell'email e nessuno sa perché. Questa guida è la mappa che usiamo nella manutenzione di parchi GLPI dei clienti per azzeccare il modello al primo colpo.
Dove vivono le variabili: un modello non è una notifica
Prima di scegliere i tag, comprenda la catena che GLPI costruisce, perché la maggior parte dei "la variabile non funziona" sono in realtà errori di configurazione, non di sintassi. Un messaggio parte solo quando quattro pezzi sono allineati:
- Notifica (Configura > Notifiche): collega l'evento - nuovo ticket, aggiornamento, soluzione, sondaggio di soddisfazione.
- Modello (Modelli di notifica): il corpo testo e il corpo HTML, dove scrive i tag
##...##. - Destinatari: chi lo riceve - richiedente, tecnico assegnato, gruppo, osservatore.
- Coda e invio: GLPI non spedisce l'email all'istante; la accoda e l'azione automatica
queuednotificationla smista.
Mettere il tag giusto in un modello non collegato ad alcuna notifica attiva non produce alcuna email - e non è colpa del tag.
I tag che usa davvero
I tag sono contestuali: l'insieme disponibile cambia in base all'oggetto (Ticket, Change, Problem). Per i ticket, questi coprono la maggior parte dei modelli - tutti verificati direttamente nel motore di notifica di GLPI 11:
| Tag | Cosa restituisce |
|---|---|
##ticket.id## | Numero del ticket |
##ticket.title## | Titolo |
##ticket.description## | Descrizione (contenuto di apertura) |
##ticket.url## | Link diretto al ticket (richiede login) |
##ticket.status## | Stato attuale |
##ticket.priority## | Priorità |
##ticket.category## | Categoria |
##ticket.creationdate## | Data di apertura |
##ticket.solvedate## | Data di soluzione |
##ticket.duedate## | Scadenza di risoluzione (SLA) |
##ticket.authors## | Richiedente/i - elenco separato da virgole |
##ticket.assigntousers## | Tecnico/i assegnato/i - elenco per virgole |
##ticket.assigntogroups## | Gruppo/i assegnato/i |
##ticket.solution## | Testo della soluzione |
##followup.author## / ##followup.description## | Dentro ##FOREACHfollowups## |
##task.author## / ##task.description## | Dentro ##FOREACHtasks## |
##author.name## / ##author.email## | Dentro ##FOREACHauthors## |
Noti che ##ticket.assigntousers## restituisce un elenco già pronto, separato da virgole - GLPI fa l'implode internamente. Non è un ciclo, è testo semplice: risolve "ho due tecnici e li voglio entrambi nell'email" senza alcun trucco.
L'errore sul campo più comune: il richiedente non è ##user.name##
Questo è, di gran lunga, il problema che riapriamo di più negli audit di modello: il nome del richiedente arriva vuoto. La causa è quasi sempre la stessa - qualcuno ha copiato ##user.name## da un tutorial di recupero password dentro una notifica di ticket. In una notifica di Ticket, ##user.name## semplicemente non esiste: appartiene alle notifiche dell'oggetto Utente (reset password, creazione account). GLPI non segnala alcun errore - sostituisce solo con una stringa vuota, e il tecnico passa il pomeriggio a inseguire un bug che è in realtà un problema di origine del dato. Il richiedente di un ticket è ##ticket.authors## (elenco pronto) oppure, se vuole nome ed email di ciascuno separatamente, il blocco FOREACH qui sotto.
FOREACH: la parte che quasi nessuno conosce
Un ticket ha N aggiornamenti, N attività, N richiedenti. Non esiste un tag magico che riversi tutto formattato: GLPI espone le collezioni tramite un blocco di ripetizione. Apra il ciclo, scriva il cuore una volta con i tag dell'elemento e lo chiuda - e può anche limitare quanti elementi con FIRST o LAST:
Ciao ##ticket.authors##,
Il tuo ticket ##ticket.id## - ##ticket.title##
e passato a: ##ticket.status##
Tecnico/i: ##ticket.assigntousers##
Ultimo aggiornamento:
##FOREACH LAST 1 followups##
[##followup.date##] ##followup.author##:
##followup.description##
##ENDFOREACHfollowups##
Accedi: ##ticket.url##Il LAST 1 (accetta anche FIRST e numeri più grandi) è ciò che evita l'email chilometrica che ripete tutta la cronologia a ogni nuovo aggiornamento - una richiesta ricorrente del cliente che la maggior parte "risolve" tagliando il contenuto a forza, quando bastava il modificatore. Le collezioni che accettano FOREACH includono followups, tasks, authors, actors, costs e le collegate (linkedtickets, linkedchanges, linkedproblems).
Notifica multilingue gratis: i tag ##lang.*##
Dettaglio che compare solo quando apre l'elenco completo dei tag: ogni tag di valore ha una compagna di etichetta. Per ##ticket.status## (il valore) esiste ##lang.ticket.status##, che stampa l'etichetta "Stato" tradotta nella lingua del destinatario. Costruendo il modello con coppie etichetta + valore, lo stesso messaggio esce in portoghese per un utente e in spagnolo per un altro, senza duplicare il modello:
##lang.ticket.title##: ##ticket.title##
##lang.ticket.status##: ##ticket.status##
##lang.ticket.priority##: ##ticket.priority##In un cliente con entità in più di un paese, questo riduce la manutenzione di "un modello per lingua" a uno solo. Il valore non lo traduce - il dato è il dato; ciò che cambia è solo l'etichetta, e ##lang.*## ci pensa da solo.
Diagnosi: la variabile è giusta, ma l'email non parte
Quando il modello è impeccabile e l'email sparisce comunque, il problema non è il tag - è la coda. GLPI scrive ogni messaggio in glpi_queuednotifications e l'azione automatica queuednotification esegue l'invio vero e proprio. Se l'azione non gira (cron fermo) o l'SMTP rifiuta, il messaggio si accumula con sent_time nullo. È la prima cosa che eseguiamo su un ticket "le notifiche non arrivano":
-- Notifiche in coda che avrebbero gia dovuto partire:
-- sent_time NULL = non ancora inviata; send_time nel passato = in ritardo.
SELECT id, name AS oggetto, recipient, send_time, sent_try
FROM glpi_queuednotifications
WHERE sent_time IS NULL
AND send_time <= NOW()
ORDER BY send_time ASC
LIMIT 30;Righe che si accumulano con sent_try che sale significano SMTP che rifiuta; coda che cresce con sent_try a zero significa cron fermo. In entrambi i casi il modello è giusto - e ha appena risparmiato il pomeriggio che avrebbe speso a riscrivere tag inutilmente.
Dove funziona ogni variabile (matrice di decisione)
La confusione che ereditiamo da quasi ogni nuovo parco è credere che "modello di ticket" e "modello di notifica" siano la stessa cosa. Non lo sono - e solo uno dei due fa la sostituzione di ##tag##:
| Dove | Sostituisce ##tag##? | A cosa serve |
|---|---|---|
| Modello di notifica (corpo e oggetto) | Sì - tag, FOREACH e ##lang.*## | Corpo email dinamico |
| Modello di ticket (TicketTemplate) | No | Predefinire, nascondere o rendere obbligatori campi all'apertura |
| Modello di attività / aggiornamento | No | Testo base riutilizzabile, senza sostituzione dinamica |
| Oggetto della notifica | Sì | Gli stessi tag del corpo, su una sola riga |
Consiglio finale che vale tutto il resto: quando modifica un modello di notifica, GLPI mostra la scheda dei tag disponibili per quell'elemento specifico. È la fonte della verità - contestuale e sempre allineata alla versione installata. Prima di copiare un tag da un blog (questo compreso), verifichi che compaia lì.
Le servono notifiche che informino davvero - multilingue, con il richiedente giusto e senza email bloccate in coda? Scopra il servizio di manutenzione GLPI di NexTool.
Revisionato dal team NexTool Solutions.
