Im Standard-GLPI gibt es keine Lesebestätigung: Die Historie des Tickets speichert, was sich geändert hat, nie aber, wer es nur geöffnet und gelesen hat. Beim Betrieb von GLPI-Umgebungen für Kunden führt das zur klassischen Pattsituation „Der Techniker hat sich das Ticket nicht einmal angesehen“ gegen „Doch, ich habe es gelesen“ – und ohne objektive Daten steht Aussage gegen Aussage. Das kostenlose Modul Ticket Tracker schließt diese Lücke, indem es jede Ticketansicht erfasst. Dieser Leitfaden zeigt, wie es die Daten speichert, wie Sie es konfigurieren, ohne die Zähler aufzublähen, und drei SQL-Abfragen, die „wer hat was gelesen“ sofort beantworten.
Warum GLPI nicht weiß, wer ein Ticket gelesen hat
Die native Historie (glpi_logs) erfasst nur Änderungen: Erstellung, Statuswechsel, neue Folgeaktion, Technikerwechsel. Das Formular zu öffnen und zu lesen ändert kein Feld und erzeugt daher auch keine Zeile. Im GLPI-Kern gibt es kein Ereignis „Ansicht“. Ticket Tracker löst das, indem es sich an der Stelle einklinkt, an der das Ticketformular gerendert wird (dem Hook postShowItem von Ticket): Jedes Mal, wenn eine authentifizierte Sitzung ein Ticket anzeigt, speichert das Modul die Ansicht. Ohne manuelle Aktion, ohne neues Feld im Formular.
Die zwei Erfassungsebenen: Zusammenfassung und Log
Das Modul schreibt in zwei Tabellen mit unterschiedlichem Zweck. Die Zusammenfassung beantwortet „wie oft und wann“; das Log beantwortet „jeder Zugriff, einzeln“:
-- Summary per (ticket, user): one row, updated on each access.
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`)
);
-- Detailed log: one row per individual access.
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`)
);Der UNIQUE-Schlüssel (tickets_id, users_id) ist das Herzstück der Zusammenfassungstabelle: Jedes Paar aus Ticket und Benutzer hat genau eine Zeile. Gespeichert wird mit INSERT ... ON DUPLICATE KEY UPDATE view_count = view_count + 1, einem atomaren Upsert – zwei gleichzeitige Zugriffe desselben Benutzers erzeugen weder eine doppelte Zeile noch geht ein Zählerstand verloren. Der Reiter „Ansichten“ im Ticket liest die Zusammenfassung (Tabelle mit allen Betrachtern, Anzahl, erster und letzter Ansicht) und bietet eine aufklappbare Kaskade, die aus dem Log jeden einzelnen Zugriff mit Datum und Uhrzeit abruft.
Aktivierung und Konfigurations-Checkliste
Das Modul ist kostenlos und wird im NexTool-Katalog aktiviert. Danach finden Sie die Konfiguration unter Module > Ticket Tracker, Reiter Funktionen:
- Modul aktiv – derselbe Schalter wie auf der Seite Module. Ist er aus, wird nichts erfasst.
- Tracking aktiv (tracking_enabled) – schaltet die Erfassung der Ansichten ein. Es kann bei ausgeblendetem Reiter eingeschaltet bleiben, wenn Sie Daten sammeln möchten, ohne sie anzuzeigen.
- Reiter im Ticket anzeigen (show_tab_on_ticket) – blendet den Reiter „Ansichten“ im Ticketformular ein oder aus.
- Mindestintervall (s) (min_interval_seconds, Standard 60) – Debounce-Fenster: Zugriffe desselben Benutzers auf dasselbe Ticket innerhalb dieses Intervalls zählen als einer.
- Ignoriert (Reiter Zusätzliche Berechtigungen) – Benutzer, Profile oder Gruppen, die ansehen, ohne erfasst zu werden. Alles leer = alle Zugriffe zählen.
Der Feldfehler, der die Zähler aufbläht (oder nullt)
Der häufige Fehler ist, das Mindestintervall auf null zu setzen, in der Annahme „je feiner, desto besser“. Der Hook feuert bei jedem Rendern des Formulars – auch beim Neuladen, beim Zurücknavigieren und beim erneuten Öffnen des Reiters. Mit min_interval_seconds = 0 werden aus einem Techniker, der das Ticket offen lässt und dreimal F5 drückt, „drei Ansichten“, und view_count verliert die Bedeutung „wie oft er sich tatsächlich wieder mit der Sache befasst hat“. Der Standard von 60 Sekunden existiert genau dafür, eine Serie von Neuladevorgängen zu einer einzigen Ansicht zusammenzufassen. Verwenden Sie 0 nur zur punktuellen Diagnose und kehren Sie danach zum Standard zurück.
Der zweite Fehler ist subtiler, und wir sind bei einem Kunden darauf gestoßen: Bis Version 1.2.0 des Moduls hing die Erfassung von der Berechtigung ab, den Reiter Ansichten zu sehen – das heißt, nur administrative Profile wurden gezählt. Anforderer und Beobachter öffneten das Ticket, und nichts wurde erfasst, sodass die Datenbasis genau diejenigen untererfasste, die bei einem SLA-Streit am meisten zählen. Wir haben die Erfassung von der Berechtigung zum Anzeigen des Reiters entkoppelt: Heute wird jede authentifizierte Sitzung gezählt, die das Ticket rendert – Anforderer, Beobachter oder Techniker –, unabhängig vom Profil. Wenn Sie eine ältere Version betreiben, aktualisieren Sie, bevor Sie den Zahlen vertrauen.
Entscheidungsmatrix: Intervall und Ignorierte je Szenario
Die richtige Einstellung hängt davon ab, was Sie belegen möchten. Die Matrix, die wir bei der Konzeption verwenden:
| Betriebsszenario | Tracking | Mindestintervall (s) | Wer unter „Ignoriert“ eingetragen wird |
|---|---|---|---|
| Lese-Audit / SLA (Standard) | Ein | 60 | Niemand |
| Umgebung mit automatischem Refresh oder Wanddisplay | Ein | 180 bis 300 | Integrationskonten / Bots |
| Aufsicht, die den Zähler nicht aufblähen soll | Ein | 60 | Profil der Manager / Auditoren |
| Punktuelle Diagnose (jeden Zugriff zählen) | Ein | 0 (vorübergehend) | Niemand |
Drei SQL-Abfragen, die sofort antworten
Der Reiter löst den Einzelfall; für den Gesamtüberblick gehen Sie direkt in die Datenbank. Offene zugewiesene Tickets, die der verantwortliche Techniker noch nicht geöffnet hat (type = 2 in glpi_tickets_users ist der zugewiesene Techniker):
-- Open assigned tickets the responsible technician has NEVER viewed.
SELECT t.id AS ticket, t.name AS title, u.name AS technician, t.date AS opened_at
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) -- new, assigned, planned, pending
AND v.id IS NULL -- no read logged by the technician
ORDER BY t.date ASC;Leselatenz – wie viele Minuten das Ticket bis zur ersten Ansicht durch den zugewiesenen Techniker offen war. Diese Kennzahl geht der ersten Antwort voraus und erklärt oft ein überschrittenes SLA:
-- Minutes between opening and the 1st read by the assigned technician.
SELECT t.id AS ticket,
TIMESTAMPDIFF(MINUTE, t.date, v.first_view) AS minutes_to_first_read
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 minutes_to_first_read DESC;Die aktivsten Betrachter eines bestimmten Tickets, aus der Zusammenfassung, um zu sehen, wer es wirklich verfolgt (ersetzen Sie 12345 durch die Ticket-ID):
-- Who opened ticket 12345 the most, from most recurrent to least.
SELECT u.name AS username, 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;Lesen ist keine Antwort: was der Zähler belegt
Die Daten sind aussagekräftig, haben aber eine ehrliche Grenze: Sie belegen, dass das Formular für diesen Benutzer gerendert wurde, nicht, dass die Person aufmerksam gelesen oder gehandelt hat. Ein hoher view_count ohne Folgeaktion ist ein gelbes Signal – jemand öffnet und schließt, ohne zu lösen. Ein Ticket ohne jede Ansicht durch den Verantwortlichen bei laufendem SLA ist ein rotes Signal – niemand hat überhaupt hingesehen. Im Betrieb liegt der eigentliche Wert nicht darin, Techniker zu überwachen, sondern die Beweislücke zu schließen: Wenn der Kunde fragt „Warum lag dieses Ticket drei Tage still?“, ist die Antwort keine Meinung mehr, sondern trägt einen Zeitstempel.
Sie brauchen echte Transparenz über die Bearbeitung in Ihrem GLPI, mit den richtigen Modulen aktiviert und auf Ihren Ablauf abgestimmt? Lernen Sie den GLPI-Betrieb von NexTool kennen.
Geprüft vom Team von NexTool Solutions.
