Im Standard-GLPI ist eine Benachrichtigung eine asynchrone E-Mail: Sie landet im Spam, Techniker leben nicht im Webmail, und eine Folgeaktion bleibt stundenlang unbeantwortet. Smart Notify ersetzt dieses Modell durch eine Glocke in der Leiste von GLPI selbst, die per Polling die Datenbank abfragt und mehr als ein Dutzend ITIL-Ereignisse nahezu in Echtzeit bündelt. Im Betrieb von Kundenlandschaften haben wir gelernt: Schwierig ist nicht, die Glocke einzuschalten - sondern zu kalibrieren, was sie anzeigt, damit sie nicht zu Rauschen wird. Dieser Leitfaden zeigt, wie der Poll im Hintergrund funktioniert, ein Diagnose-SQL, eine Matrix der Ereignisse, die aktiv bleiben sollten, und die Fallstricke, an denen die Installation am häufigsten scheitert.
Warum native E-Mails operative Benachrichtigungen nicht lösen
Die nativen Benachrichtigungen von GLPI hängen von der Warteschlange queuednotification und von E-Mail-Vorlagen ab. Es ist ein asynchrones Modell außerhalb des Tools: Techniker müssen zwischen GLPI und Posteingang wechseln, transaktionale E-Mails landen im Unternehmens-Spam, und niemand verfolgt den Webmail in Echtzeit. Klassisches Ergebnis im Betrieb: stundenlang liegengebliebene Genehmigungen und zugewiesene Aufgaben, die niemand gesehen hat.
Die Glocke löst dies für alle, die in GLPI angemeldet sind. Doch Achtung beim ersten Fallstrick: Die Glocke ersetzt nicht die E-Mail an den Anforderer. Sie benachrichtigt Techniker in einer aktiven Sitzung, nicht den Kunden, der ein Ticket über das Self-Service erstellt hat. Der häufige Fehler ist, die E-Mail-Benachrichtigungen abzuschalten in der Annahme, die Glocke decke alle ab - und der Anforderer wird nicht mehr informiert. Glocke und E-Mail sind sich ergänzende Ebenen, keine sich ausschließenden.
Wie die Glocke im Hintergrund funktioniert (Polling + Delta)
Der JavaScript-Code der Glocke führt alle 30 Sekunden (Standard-refresh_interval) einen Poll gegen einen AJAX-Endpunkt aus. In jedem Zyklus durchsucht ein Backend bis zu sechzehn Ereignisquellen, erstellt eine Liste, wendet die Aufbewahrung an (retention_days, Standard 90 Tage), kürzt auf max_notifications (Standard 50) und sortiert absteigend nach Datum. Jede Benachrichtigung erhält einen stabilen Hash (sha1(tipo_id_timestamp)) - er markiert einen Eintrag als gelesen, ohne ein neues Feld im Ticket zu benötigen.
Was nur auffällt, wer betreibt, sind die Kosten dieses Polls alle 30 s pro angemeldetem Techniker. Deshalb nutzt der Endpunkt den Delta-Modus: Der Client sendet den Hash des letzten Zustands (state=) zurück; hat sich nichts geändert, sinkt die Antwort von etwa 18 KB auf ~93 Bytes. Und der Read-Check wurde zu einem einzigen SELECT im Batch - vorher war es ein SELECT pro Benachrichtigung, bis zu ~700 pro Poll bei Benutzern mit großem Rückstand. Der GET ruft außerdem gleich zu Beginn session_write_close() auf, um den PHP-Sitzungs-Lock nicht zu halten, während die Datenbank durchsucht wird.
# O sino faz polling a cada 30s neste endpoint (roteado pelo module_ajax):
GET /plugins/nextool/ajax/module_ajax.php?module=smartnotify&file=notifications.php&action=get&state=${HASH}
# Sem novidade desde o ultimo poll, a resposta e um delta de ~93 bytes:
{ "success": true, "unchanged": true, "state": "...md5...", "unread_count": 4 }
# So quando algo muda vem o payload completo (~18KB) com o array notifications[].Die Ereignisquellen und was aktiv bleiben sollte
Die globale Konfiguration stellt sechzehn Auslöser bereit, und jeder Techniker verfeinert seine eigenen zusätzlich im Einstellungsdialog (direkt über ein Dropdown der Glocke erreichbar). Zwei Targeting-Regeln sind wichtig: Eine Folgeaktion, die Sie selbst geschrieben haben, benachrichtigt Sie nicht (die Query filtert users_id != usuário), und Benachrichtigungen kommen bei direkter Beteiligung oder über die Technikergruppe (notify_group_involvement) an, stets unter Beachtung der aktiven Einheiten der Sitzung.
Im Betrieb sind drei Auslöser absichtlich standardmäßig deaktiviert, und die Erfahrung bestätigt diese Wahl: Angehängte Dokumente sind Rauschen in Landschaften mit vielen Uploads; neue Probleme und neue Änderungen sind seltenere Ereignisse, welche die Glocke von Technikern verstopfen, die sich nur um Tickets kümmern. Alles einzuschalten ist der schnellste Weg zur Alarmmüdigkeit - Techniker ignorieren die Glocke, und dann nützt sie nichts mehr.
| Ereignisfamilie | Auslöser (Konfiguration) | Standard | Praxishinweis |
|---|---|---|---|
| Folgeaktionen (Ticket, Problem, Änderung) | notify_*_followup | Aktiv | Bewegt den Rückstand am meisten; beibehalten |
| Genehmigungen und Genehmigungsantworten | notify_*_validation(_response) | Aktiv | Eine hängende Genehmigung ist ein stiller Engpass |
| Zugewiesene Aufgaben | notify_*_task | Aktiv | Arbeitswarteschlange der Techniker |
| Erfasste Lösungen | notify_solution | Aktiv | Schließt den Kreis für alle, die mitverfolgen |
| Angehängte Dokumente | notify_document | Inaktiv | Laut, wo viele Anhänge anfallen |
| Neue Tickets | notify_new_ticket | Aktiv | Eingangssignal der Warteschlange |
| Neue Probleme / Änderungen | notify_new_problem / _change | Inaktiv | Seltener; je Profil einschalten |
| Manuelle Hinweise (Broadcast) | notify_manual | Aktiv | Wartung, Prozessänderung |
Diagnose per SQL: Wer hat was stummgeschaltet?
Wenn ein Kunde klagt, "die Glocke meldet nichts", ist die Ursache fast immer eine individuelle Einstellung oder eine falsche Einheit, kein Bug. Diese drei Abfragen erledigen die Triage direkt in der Datenbank (reale Tabellen des Moduls):
-- 1. Quantos tecnicos silenciaram cada tipo de evento (acha ruido/fadiga):
SELECT
SUM(ticket_followups = 0) AS mudo_followup_ticket,
SUM(solutions = 0) AS mudo_solucao,
SUM(documents = 0) AS mudo_documento,
SUM(sound_enabled = 0) AS som_desligado
FROM glpi_plugin_nextool_smartnotify_preferences;
-- 2. Registros de leitura por usuario (backlog e ultima atividade):
SELECT users_id, COUNT(*) AS lidas_registradas, MAX(date_read) AS ultima_leitura
FROM glpi_plugin_nextool_smartnotify_read
GROUP BY users_id
ORDER BY ultima_leitura DESC;
-- 3. Broadcasts manuais ativos e seu alvo (all/user/group/entity):
SELECT id, title, priority, target_type, target_id, entities_id, date_creation
FROM glpi_plugin_nextool_smartnotify_manual
WHERE is_active = 1
ORDER BY date_creation DESC;Töne nach Priorität und die Autoplay-Falle
Benachrichtigungen geben über die Web Audio API einen Ton aus, mit vier nach Priorität zugeordneten Klangfarben. Techniker hören, bevor sie auf den Bildschirm schauen, ob es Routine oder Dringendes ist:
| Priorität | Ton | Klangfarbe (ca.) |
|---|---|---|
| Niedrig | subtle | Kurz und tief (440 Hz) |
| Normal | default | Standard (523 Hz) |
| Hoch | alert | Mittel (659 Hz) |
| Dringend | alarm | Lang und hoch (880 Hz) |
Diese Falle liegt nicht am Modul, sondern am Browser: Die Autoplay-Richtlinie von Chrome erlaubt es erst nach der ersten Benutzerinteraktion, einen AudioContext zu erzeugen. In der Praxis erklingt der erste Ton einer Sitzung erst nach dem ersten Klick auf die Seite. Jeden Monat erstellt jemand ein Ticket mit "der Ton funktioniert nicht" - die Antwort lautet: einmal auf die Seite klicken. Kein Bug, sondern die Web Audio API, die den Browser respektiert.
Manuelle Broadcasts und automatische Bereinigung
Administratoren senden manuelle Hinweise mit präzisem Targeting: alle, ein Benutzer, eine Gruppe oder eine Einheit (Spalte target_type in der Tabelle _manual). Dies ist der richtige Kanal für Wartungsfenster oder Prozessänderungen, ohne E-Mails an alle Benutzer zu verschicken. Um die Aufbewahrung kümmert sich eine tägliche CronTask (smartnotify_cleanup), die bei der Installation als MODE_EXTERNAL registriert wird. Dies ist wichtig: Im MODE_INTERNAL läuft die Aufgabe per Web-Hit und kann in state=2 hängen bleiben. Lösen Sie den GLPI-Cron extern aus (in GLPI 11 front/cron.php), und die Bereinigung erfolgt von selbst gemäß retention_days und logs_retention_days.
# CronTask registrada no install (idempotente), 1x/dia, MODE_EXTERNAL:
# Nome: smartnotify_cleanup Frequencia: DAY_TIMESTAMP (86400s)
# Dispare o cron do GLPI por fora (nunca dependa do MODE_INTERNAL via web-hit):
* * * * * www-data /usr/bin/php /var/www/html/front/cron.php >/dev/null 2>&1Die Falle, an der die Installation scheitert: MySQL 8 vs. MariaDB
Ein realer Fall aus dem Betrieb (Juni 2026, Kunde mit MySQL 8.0.46): Die Installation des Moduls endete mit HTTP 500, und die Landschaft blieb ohne Glocke. Die eigentliche Ursache lag nicht in GLPI, sondern im SQL: ein Block ALTER TABLE ... ADD COLUMN IF NOT EXISTS - eine Syntax, die ausschließlich MariaDB kennt. In MySQL 8 gibt es dieses IF NOT EXISTS für Spalten nicht, und die Anweisung scheitert mit Fehler 1064, wodurch die gesamte Installation abbricht. Die Lehre gilt für jedes GLPI-Plugin: Bedingtes DDL ist zwischen MariaDB und MySQL nicht portabel. Die Korrektur (Version 2.2.1+) entfernte bedingtes DDL aus der .sql und verlagerte die Migrationen nach PHP, mit portablen Helpern des Basis-Plugins. Wenn Sie MySQL 8 betreiben, stellen Sie sicher, dass Sie mindestens Version 2.2.1 des Moduls einsetzen.
Bei NexTool implementieren und betreiben wir GLPI-Umgebungen von Anfang bis Ende. Wenn Ihr Team mit vergessenen Tickets und E-Mail-Benachrichtigungen kämpft, die niemand öffnet: Smart Notify ist kostenlos und in wenigen Minuten über den NexTool-Modulkatalog aktiviert - und unser Betriebsteam hilft zu kalibrieren, was jedes Profil erhält, damit die Glocke zum Signal wird und nicht zum Rauschen.
Geprüft vom Team der NexTool Solutions.
