NexTool Solutions

Il ticket più economico è quello che non viene mai aperto. Quando l'utente vede un avviso chiaro sulla schermata stessa di GLPI prima di segnalare qualcosa di già noto, non apre il ticket - e la coda del service desk smette di riempirsi di duplicati sulla stessa manutenzione o sullo stesso incidente. Il plugin News risolve esattamente questo: banner di avviso, comunicato e manutenzione dentro l'interfaccia, per i tecnici e per chi usa il self-service. Gestendo parchi di clienti ogni giorno, abbiamo imparato che accendere il banner è la parte facile; ciò che separa una comunicazione utile da un portale intasato sono la segmentazione giusta, la data di fine e la disciplina di rimuovere l'avviso quando non vale più.

Avviso statico vs notifica al tecnico: non li confonda

Prima di installare qualsiasi cosa, conviene separare due problemi diversi. L'avviso statico (plugin News, o i Promemoria Pubblici nativi) parla a chi non ha ancora aperto il ticket - è comunicazione preventiva sul self-service e sulla dashboard. La notifica al tecnico (e-mail nativa o la campanella di Smart Notify) parla a chi sta già gestendo il ticket. L'errore comune è credere che uno copra l'altro: spegnere l'e-mail perché c'è un banner, o mettere un banner aspettandosi che il tecnico venga avvisato di un followup. Sono livelli complementari. Il plugin News è il livello esterno - quello che evita che il ticket nasca.

Installare e localizzare il plugin News

News è distribuito tramite il Marketplace di GLPI e il repository ufficiale. Dopo averlo scaricato in plugins/news, lo installi e lo attivi. Da riga di comando, lo esegua come utente del server web - la trappola qui è usare --allow-superuser o girare come root, cosa che scrive file con proprietario sbagliato e poi rompe il cron:

# GLPI 10/11 (CLI) - esegui come utente del server web, mai con --allow-superuser:
docker exec --user apache glpi php bin/console glpi:plugin:install news
docker exec --user apache glpi php bin/console glpi:plugin:activate news

# Alternativa da interfaccia: Configurazione > Plugin, pulsante Installa e poi Attiva.

Con il plugin attivo, la gestione degli avvisi si trova di solito in Strumenti > Avvisi (l'etichetta può variare a seconda della versione). Ogni avviso ha quattro decisioni che contano: il tipo, il messaggio, dove e a chi appare, e per quanto tempo.

Anatomia di un avviso: i campi che contano

Il tipo definisce il colore e la lettura semantica del banner - l'utente decodifica l'urgenza prima di leggere il testo. Usi la semantica con parsimonia: se tutto è rosso, niente è urgente.

La visibilità controlla due assi: dove appare il banner (la schermata centrale del tecnico, il portale self-service, la schermata di login) e a chi (tutti, profili, gruppi o entità specifiche). Qui vive la trappola che più imbarazza nelle installazioni multi-entità: creare l'avviso sull'entità radice con "ricorsivo" attivo fa trapelare l'avviso nel self-service di TUTTI i clienti che condividono la stessa istanza. Un comunicato di manutenzione del Cliente A appare per il Cliente B. In gestione, la regola è delimitare ogni avviso all'entità specifica e usare la radice ricorsiva solo per avvisi che valgono per l'intera base, come una politica di apertura ticket.

Il periodo (data di inizio e fine) è il campo che tutti sottovalutano - ed è quello che intasa di più il portale nel tempo.

Modello pronto: banner di manutenzione pianificata

Il messaggio accetta HTML, quindi può standardizzare un banner leggibile invece di un paragrafo continuo. Questo modello chiarisce cosa cade, quando torna e cosa deve fare l'utente. Lo copi, regoli i valori e lo incolli nel campo messaggio:

<strong>Manutenzione pianificata - Sistema di posta</strong><br>
Finestra: 15/07/2026, dalle 22h00 alle 02h00 (ora locale).<br>
Impatto: la webmail e l'invio dei messaggi non saranno disponibili.<br>
Cosa fare: rimanda gli invii critici a dopo le 02h00.<br>
<em>Non e necessario aprire un ticket su questa indisponibilita.</em>

Quell'ultima riga - "non è necessario aprire un ticket" - fa più per ridurre la coda dell'intero banner. È l'istruzione esplicita che l'utente cerca prima di decidere di segnalare.

La trappola dell'"avviso eterno" e l'SQL di igiene

In ogni installazione che prendiamo in gestione, lo schema si ripete: il portale self-service ha accumulato sei o otto vecchi banner che nessuno ha fatto scadere. L'utente impara a ignorare l'intera fascia - è la cecità da banner - e quando arriva un avviso che conta, nessuno lo legge. La causa radice è quasi sempre un avviso senza data di fine. Peggio ancora è il banner "siamo a conoscenza della lentezza" rimasto attivo tre giorni dopo la risoluzione dell'incidente, che segnala un blackout già finito ed erode la fiducia nel canale. Abbiamo adottato una scansione mensile direttamente sul database. Prima scopra lo schema reale (i nomi delle colonne variano tra le versioni del plugin), poi cacci gli eterni:

-- 1. Individuare la tabella degli avvisi del plugin News:
SHOW TABLES LIKE 'glpi_plugin_news_%';

-- 2. Verificare i nomi reali delle colonne (variano per versione del plugin):
DESCRIBE glpi_plugin_news_alerts;

-- 3. Avvisi "eterni" - senza data di fine, la causa radice della cecita da banner:
SELECT id, name, type, date_start, date_end
FROM glpi_plugin_news_alerts
WHERE date_end IS NULL OR date_end = '0000-00-00 00:00:00'
ORDER BY date_start;

-- 4. Avvisi ancora attivi la cui finestra e gia passata (dimenticati di rimuovere):
SELECT id, name, type, date_end
FROM glpi_plugin_news_alerts
WHERE date_end IS NOT NULL
  AND date_end < NOW()
ORDER BY date_end DESC;

La query 4 è quella che sorprende di più il cliente: elenca l'incidente "già risolto" ma ancora a schermo. Eseguirla una volta al mese mantiene il canale credibile - ed è economico.

News, Promemoria Pubblici o Smart Notify: quale usare

Non ogni comunicato richiede un plugin. GLPI ha i Promemoria Pubblici nativi, e NexTool mantiene Smart Notify per il lato dinamico. Ognuno risolve un segmento:

In pratica: usi i Promemoria Pubblici nativi per una nota semplice senza installare nulla; il plugin News quando serve un banner colorato per tipo, segmentazione per schermata e avviso sulla schermata di login; e Smart Notify per l'altra faccia della medaglia - avvisare il tecnico, quasi in tempo reale, di followup, validazioni e attività dentro GLPI stesso. Non competono: News evita che il ticket nasca, Smart Notify accelera il ticket che già esiste.

Buone pratiche di comunicazione (dalla gestione operativa)

• Ogni messaggio ha una data di fine. Senza eccezioni. Se non sa quando scade l'avviso, non sa perché lo sta pubblicando.
• Comunichi la manutenzione con 24h di anticipo e tenga il banner fino alla fine della finestra. Per finestre pianificate annunciate in anticipo, abbiamo visto calare in modo netto la coda di duplicati su "sistema giù" - lo tratti come un intervallo onesto, non un numero magico.
• Rimuova il banner di incidente appena risolto. Un avviso di blackout ancora attivo dopo il blackout è peggio di nessun avviso.
• Non impili i banner. Tre avvisi simultanei sul self-service sono già rumore; il quarto non lo legge nessuno.
• Delimiti per entità sulle istanze multi-cliente. Ricorsivo sulla radice solo per ciò che vale per tutti.
• Colori con significato. Il rosso è incidente attivo, non "leggi con attenzione".

In NexTool trattiamo la comunicazione in GLPI come parte della gestione operativa: configuriamo i canali giusti, definiamo la politica di scadenza degli avvisi e incrociamo comunicazione statica e notifica dinamica per il parco del cliente. Se vuole andare oltre il banner, il modulo Smart Notify copre il lato del tecnico, e il nostro team di gestione aiuta a disegnare il flusso completo.

Revisionato dal team NexTool Solutions.