NexTool Solutions

In GLPI standard non esiste alcuna registrazione di lettura: la cronologia del ticket conserva ciò che è cambiato, mai chi lo ha semplicemente aperto e letto. Nella manutenzione di parchi GLPI di clienti, questo diventa il classico stallo del "il tecnico non ha nemmeno guardato il ticket" contro "sì, l'ho letto" - e senza un dato oggettivo è la parola di uno contro quella dell'altro. Il modulo gratuito Ticket Tracker colma questa lacuna registrando ogni visualizzazione di ticket. Questa guida mostra come archivia i dati, come configurarlo senza gonfiare i contatori e tre query SQL che rispondono "chi ha letto cosa" all'istante.

Perché GLPI non sa chi ha letto un ticket

La cronologia nativa (glpi_logs) registra solo le modifiche: creazione, cambio di stato, nuovo followup, riassegnazione del tecnico. Aprire il modulo e leggerlo non modifica alcun campo, quindi non produce alcuna riga. Nel cuore di GLPI non esiste un evento di "visualizzazione". Ticket Tracker lo risolve agganciandosi al momento in cui il modulo del ticket viene renderizzato (l'hook postShowItem del Ticket): ogni volta che una sessione autenticata mostra un ticket, il modulo registra la visualizzazione. Senza azione manuale, senza un nuovo campo nel modulo.

I due livelli di registrazione: riepilogo e log

Il modulo scrive su due tabelle con scopi distinti. Quella di riepilogo risponde "quante volte e quando"; quella di log risponde "ogni accesso, uno per uno":

-- Riepilogo per (ticket, utente): una riga, aggiornata a ogni accesso.
CREATE TABLE `glpi_plugin_nextool_tickettracker_views` (
  `id`         int unsigned NOT NULL AUTO_INCREMENT,
  `tickets_id` int unsigned NOT NULL,
  `users_id`   int unsigned NOT NULL,
  `view_count` int unsigned NOT NULL DEFAULT 1,
  `first_view` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `last_view`  timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  UNIQUE KEY `uniq_ticket_user` (`tickets_id`, `users_id`)
);

-- Log dettagliato: una riga per ogni accesso individuale.
CREATE TABLE `glpi_plugin_nextool_tickettracker_viewlog` (
  `id`         int unsigned NOT NULL AUTO_INCREMENT,
  `tickets_id` int unsigned NOT NULL,
  `users_id`   int unsigned NOT NULL,
  `view_date`  timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`)
);

La chiave UNIQUE (tickets_id, users_id) è il cuore della tabella di riepilogo: ogni coppia ticket/utente ha esattamente una riga. La scrittura usa INSERT ... ON DUPLICATE KEY UPDATE view_count = view_count + 1, un upsert atomico - due accessi simultanei dello stesso utente non creano righe duplicate né perdono il conteggio. La scheda "Visualizzazioni" nel ticket legge il riepilogo (tabella con tutti i lettori, conteggio, prima e ultima lettura) e offre una cascata espandibile che estrae dal log ogni accesso individuale, con data e ora.

Attivazione e checklist di configurazione

Il modulo è gratuito e si attiva dal catalogo NexTool. Una volta abilitato, la configurazione si trova in Moduli > Ticket Tracker, scheda Funzionalità:

1. Modulo attivo - lo stesso interruttore della pagina Moduli. Spento, non viene tracciato nulla.
2. Tracciamento attivo (tracking_enabled) - attiva la registrazione delle visualizzazioni. Può restare attivo con la scheda nascosta, se vuoi raccogliere senza esporre.
3. Mostra scheda sul ticket (show_tab_on_ticket) - mostra o nasconde la scheda "Visualizzazioni" nel modulo del ticket.
4. Intervallo minimo (s) (min_interval_seconds, predefinito 60) - una finestra di debounce: gli accessi dello stesso utente allo stesso ticket entro quell'intervallo contano come uno.
5. Ignorati (scheda Permessi aggiuntivi) - utenti, profili o gruppi che visualizzano senza essere tracciati. Tutto vuoto = ogni accesso conta.

L'errore di campo che gonfia (o azzera) i contatori

L'errore comune è azzerare l'intervallo minimo pensando "più è granulare, meglio è". L'hook scatta a ogni render del modulo - inclusi ricaricamenti, navigazione indietro e riaperture della scheda. Con min_interval_seconds = 0, un tecnico che lascia il ticket aperto e aggiorna tre volte diventa "tre letture", e view_count perde il senso di "quante volte è davvero tornato sull'argomento". Il valore predefinito di 60 secondi esiste proprio per comprimere la raffica di ricaricamenti in un'unica lettura. Usa 0 solo per una diagnosi puntuale e torna poi al valore predefinito.

Il secondo errore è più sottile e ci siamo imbattuti in esso presso un cliente: fino alla versione 1.2.0 del modulo, la registrazione dipendeva dal permesso di vedere la scheda Visualizzazioni - cioè venivano contati solo i profili amministrativi. Il richiedente e gli osservatori aprivano il ticket e non veniva registrato nulla, quindi la base sotto-riportava proprio chi conta di più in una disputa di SLA. Abbiamo disaccoppiato la registrazione dal permesso di vedere la scheda: oggi qualsiasi sessione autenticata che renderizza il ticket viene conteggiata - richiedente, osservatore o tecnico - indipendentemente dal profilo. Se usi una versione precedente, aggiorna prima di fidarti dei numeri.

Matrice di decisione: intervallo e ignorati per scenario

La regolazione giusta dipende da cosa vuoi dimostrare. La matrice che usiamo in fase di progettazione:

Tre query SQL che rispondono all'istante

La scheda risolve il caso per caso; per una vista di parco, vai dritto al database. Ticket aperti assegnati che il tecnico responsabile non ha ancora aperto (type = 2 in glpi_tickets_users è il tecnico assegnato):

-- Ticket aperti assegnati che il tecnico responsabile non ha MAI visualizzato.
SELECT t.id AS ticket, t.name AS titolo, u.name AS tecnico, t.date AS aperto_il
FROM glpi_tickets t
JOIN glpi_tickets_users tu ON tu.tickets_id = t.id AND tu.type = 2
JOIN glpi_users u ON u.id = tu.users_id
LEFT JOIN glpi_plugin_nextool_tickettracker_views v
       ON v.tickets_id = t.id AND v.users_id = tu.users_id
WHERE t.is_deleted = 0
  AND t.status IN (1, 2, 3, 4)   -- nuovo, assegnato, pianificato, in attesa
  AND v.id IS NULL               -- nessuna lettura registrata dal tecnico
ORDER BY t.date ASC;

Latenza di lettura - quanti minuti il ticket è rimasto aperto fino alla prima lettura del tecnico assegnato. È la metrica che precede la prima risposta e spesso spiega uno SLA sforato:

-- Minuti tra l'apertura e la 1a lettura del tecnico assegnato.
SELECT t.id AS ticket,
       TIMESTAMPDIFF(MINUTE, t.date, v.first_view) AS minuti_alla_1a_lettura
FROM glpi_tickets t
JOIN glpi_tickets_users tu ON tu.tickets_id = t.id AND tu.type = 2
JOIN glpi_plugin_nextool_tickettracker_views v
       ON v.tickets_id = t.id AND v.users_id = tu.users_id
WHERE t.is_deleted = 0
ORDER BY minuti_alla_1a_lettura DESC;

I lettori più attivi di un ticket specifico, dal riepilogo, per sapere chi lo segue davvero (sostituisci 12345 con l'ID del ticket):

-- Chi ha aperto di più il ticket 12345, dal più ricorrente al meno.
SELECT u.name AS utente, v.view_count, v.first_view, v.last_view
FROM glpi_plugin_nextool_tickettracker_views v
JOIN glpi_users u ON u.id = v.users_id
WHERE v.tickets_id = 12345
ORDER BY v.view_count DESC;

Leggere non è rispondere: cosa dimostra il contatore

Il dato è potente, ma ha un limite onesto: dimostra che il modulo è stato renderizzato per quell'utente, non che la persona l'ha letto con attenzione né che ha agito. Un view_count alto senza followup è un segnale giallo - qualcuno apre e chiude senza risolvere. Un ticket con zero visualizzazioni del responsabile mentre lo SLA corre è un segnale rosso - nessuno l'ha nemmeno guardato. Nella manutenzione, il valore reale non è sorvegliare il tecnico, è colmare il vuoto probatorio: quando il cliente chiede "perché questo ticket è rimasto fermo tre giorni?", la risposta smette di essere un'opinione e ottiene un timbro con data e ora.

Ti serve una visibilità reale sull'assistenza nel tuo GLPI, con i moduli giusti attivati e regolati sul tuo flusso? Scopri il servizio di manutenzione GLPI di NexTool.

Questo contenuto è stato prodotto con l'ausilio dell'intelligenza artificiale e revisionato dal team Nextool Solutions.