Das günstigste Ticket ist eines, das nie erstellt wird. Wenn der Benutzer direkt in GLPI einen klaren Hinweis sieht, bevor er etwas bereits Bekanntes meldet, erstellt er kein Ticket - und die Warteschlange des Service Desk füllt sich nicht mehr mit Duplikaten zur selben Wartung oder zur selben Störung. Genau dafür ist Plugin News gemacht: Banner für Warnungen, Mitteilungen und Wartungen in der Oberfläche, für Techniker und für Self-Service-Benutzer. Beim Betrieb der Umgebungen unserer Kunden haben wir gelernt, dass sich ein Banner leicht einschalten lässt; was eine nützliche Kommunikation von einem überladenen Portal unterscheidet, sind die richtige Zielgruppe, ein Enddatum und die Disziplin, den Hinweis zu entfernen, sobald er nicht mehr gilt.
Statischer Hinweis vs. Benachrichtigung an den Techniker: nicht verwechseln
Bevor Sie etwas installieren, lohnt es sich, zwei verschiedene Probleme zu trennen. Der statische Hinweis (Plugin News oder die nativen öffentlichen Erinnerungen) richtet sich an Personen, die noch kein Ticket erstellt haben - präventive Kommunikation im Self-Service und im Dashboard. Die Benachrichtigung an den Techniker (native E-Mail oder die Glocke von Smart Notify) richtet sich an Personen, die ein Ticket bereits bearbeiten. Der häufige Fehler ist zu glauben, eine ersetze die andere: E-Mails abschalten, weil es ein Banner gibt, oder ein Banner setzen in der Erwartung, dass der Techniker über eine Folgeaktion informiert wird. Es sind sich ergänzende Ebenen. Plugin News ist die äußere Ebene - jene, die verhindert, dass ein Ticket überhaupt entsteht.
Plugin News installieren und finden
News wird über den GLPI-Marketplace und über sein offizielles Repository verteilt. Nach dem Herunterladen nach plugins/news installieren und aktivieren Sie es. Auf der Kommandozeile führen Sie die Befehle als Benutzer des Webservers aus - die Falle hier ist, --allow-superuser zu verwenden oder als root zu arbeiten, wodurch Dateien mit falschem Eigentümer geschrieben werden und später der Cron bricht:
# GLPI 10/11 (CLI) - rode como o usuario do servidor web, nunca com --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 pela interface: Configurar > Plugins, botao Instalar e depois Ativar.Bei aktivem Plugin liegt die Verwaltung der Hinweise meist unter Werkzeuge > Warnungen (die Bezeichnung kann je nach Version abweichen). Jede Warnung umfasst vier wichtige Entscheidungen: den Typ, die Nachricht, wo und für wen sie erscheint und wie lange.
Aufbau einer Warnung: die wichtigen Felder
Der Typ bestimmt Farbe und semantische Bedeutung des Banners - der Benutzer erfasst die Dringlichkeit, bevor er den Text liest. Gehen Sie sparsam mit dieser Semantik um: Wenn alles rot ist, ist nichts dringend.
| Typ | Farbe / Bedeutung | Wann verwenden | Beispiel |
|---|---|---|---|
| Information | Blau - neutral | Allgemeine Mitteilung, Neuigkeit | „Neue GLPI-Version verfügbar“ |
| Hinweis | Gelb - Aufmerksamkeit | Etwas zu beachten, ohne Dringlichkeit | „Geben Sie beim Erstellen eines Tickets die Inventarnummer an“ |
| Problem | Rot - kritisch | Laufende aktive Störung | „Wir wissen von der Verlangsamung beim E-Mail-Dienst“ |
| Wartung | Hervorgehoben - geplant | Geplantes Zeitfenster mit fester Uhrzeit | „System X in Wartung am 15.07., 22-2 Uhr“ |
Die Sichtbarkeit steuert zwei Achsen: wo der Banner erscheint (Startseite des Technikers, Self-Service-Portal, Anmeldeseite) und für wen (alle, Profile, Gruppen oder bestimmte Einheiten). Hier liegt die Falle, die in Installationen mit mehreren Einheiten am häufigsten für Peinlichkeiten sorgt: Wird die Warnung in der Stamm-Einheit mit aktivierter Option „rekursiv“ angelegt, gelangt der Hinweis in den Self-Service ALLER Kunden, die sich dieselbe Instanz teilen. Eine Wartungsmitteilung für Kunde A erscheint bei Kunde B. In unserem Betrieb gilt: Jede Warnung wird auf die konkrete Einheit beschränkt, und die rekursive Stamm-Einheit wird nur für Mitteilungen verwendet, die für alle gelten, etwa eine Richtlinie zum Erstellen von Tickets.
Der Zeitraum (Start- und Enddatum) ist jenes Feld, das alle unterschätzen - und genau jenes, das mit der Zeit am meisten Ballast im Portal erzeugt.
Fertige Vorlage: Banner für geplante Wartung
Die Nachricht akzeptiert HTML, sodass Sie einen gut lesbaren Banner standardisieren können statt eines Fließtextabsatzes. Diese Vorlage macht klar, was ausfällt, wann es zurück ist und was der Benutzer tun soll. Kopieren Sie sie, passen Sie die Werte an und fügen Sie sie in ein Nachrichtenfeld ein:
<strong>Manutencao programada - Sistema de E-mail</strong><br>
Janela: 15/07/2026, das 22h00 as 02h00 (horario de Brasilia).<br>
Impacto: o webmail e o envio de mensagens ficarao indisponiveis.<br>
O que fazer: adie envios criticos para apos as 02h00.<br>
<em>Nao e necessario abrir chamado sobre esta indisponibilidade.</em>Die letzte Zeile - „Es ist nicht nötig, ein Ticket zu erstellen“ - trägt mehr zur Entlastung der Warteschlange bei als der ganze restliche Banner. Es ist genau die ausdrückliche Anweisung, nach der der Benutzer sucht, bevor er entscheidet, etwas zu melden.
Die Falle der „ewigen Warnung“ und ein Hygiene-SQL
In jeder Installation, deren Betrieb wir übernehmen, wiederholt sich dieses Muster: Im Self-Service-Portal haben sich sechs, acht alte Banner angesammelt, die niemand ablaufen ließ. Der Benutzer lernt, den ganzen Streifen zu ignorieren - Bannerblindheit - und wenn ein wichtiger Hinweis kommt, liest ihn niemand. Die eigentliche Ursache ist fast immer eine Warnung ohne Enddatum. Noch schlimmer ist ein Banner „Wir wissen von der Verlangsamung“, der drei Tage nach Behebung der Störung noch online ist, einen längst beendeten Ausfall meldet und so dem Kanal Vertrauen entzieht. Wir haben einen monatlichen Durchlauf direkt in der Datenbank eingeführt. Ermitteln Sie zuerst ein reales Schema (die Spaltennamen unterscheiden sich zwischen Plugin-Versionen) und suchen Sie dann nach ewigen Warnungen:
-- 1. Localizar a tabela de alertas do plugin News:
SHOW TABLES LIKE 'glpi_plugin_news_%';
-- 2. Conferir os nomes reais das colunas (variam por versao do plugin):
DESCRIBE glpi_plugin_news_alerts;
-- 3. Alertas "eternos" - sem data de fim, a causa raiz da cegueira de 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. Alertas ainda ativos cuja janela ja passou (esqueceram de remover):
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;Abfrage 4 überrascht Kunden am meisten: Sie listet jene Störung auf, die „bereits behoben“ ist, aber weiterhin auf dem Bildschirm steht. Einmal im Monat ausgeführt, erhält sie die Glaubwürdigkeit des Kanals - und kostet wenig.
News, öffentliche Erinnerungen oder Smart Notify: was verwenden
Nicht jede Mitteilung braucht ein Plugin. GLPI hat native öffentliche Erinnerungen, und NexTool pflegt Smart Notify für die dynamische Seite. Jedes Werkzeug deckt einen eigenen Bereich ab:
| Kriterium | Öffentliche Erinnerungen (nativ) | Plugin News | Smart Notify (NexTool) |
|---|---|---|---|
| Art | Einfacher Text/Hinweis | Statischer Banner nach Typ | Dynamische Benachrichtigung (Glocke) |
| Zielgruppe | Wer noch kein Ticket erstellt hat | Wer noch kein Ticket erstellt hat | Angemeldeter Techniker |
| Wo es erscheint | Planungsbereich / Startseite | Startseite, Self-Service und Anmeldung | Glocke in der Navigationsleiste von GLPI |
| Segmentierung | Profil / Einheit | Typ, Seite, Profil, Gruppe, Einheit | Nach Ereignis und nach Techniker |
| Farbe nach Schweregrad | Nein | Ja (Info / Hinweis / Problem) | Ton nach Priorität |
| Plugin-Installation nötig | Nein (nativ) | Ja | Ja (NexTool-Modul) |
| Am besten für | Kurze Notiz ohne Plugin | Wartung und Störung im Self-Service | Den Techniker über Änderungen informieren |
In der Praxis: Verwenden Sie die nativen öffentlichen Erinnerungen für eine einfache Notiz ohne Installation; Plugin News, wenn Sie einen farbigen Banner nach Typ, Segmentierung nach Seite und einen Hinweis auf der Anmeldeseite brauchen; und Smart Notify für die andere Seite der Medaille - den Techniker nahezu in Echtzeit direkt in GLPI über Folgeaktionen, Genehmigungen und Aufgaben zu informieren. Sie konkurrieren nicht: News verhindert, dass ein Ticket entsteht, Smart Notify beschleunigt ein bestehendes Ticket.
Bewährte Kommunikationspraxis (aus dem Betrieb)
- Jede Nachricht hat ein Enddatum. Ohne Ausnahme. Wenn Sie nicht wissen, wann ein Hinweis abläuft, wissen Sie nicht, warum Sie ihn veröffentlichen.
- Kündigen Sie Wartungen 24 Stunden im Voraus an und lassen Sie den Banner bis zum Ende des Zeitfensters stehen. Bei geplanten, rechtzeitig angekündigten Zeitfenstern haben wir gesehen, dass die Duplikate zu „System ausgefallen“ deutlich zurückgingen - betrachten Sie dies als ehrliche Spanne, nicht als magische Zahl.
- Entfernen Sie den Störungsbanner, sobald sie behoben ist. Ein Ausfallhinweis, der nach dem Ausfall noch online ist, ist schlimmer als gar keiner.
- Stapeln Sie keine Banner. Drei gleichzeitige Hinweise im Self-Service sind schon Rauschen; einen vierten liest niemand.
- Beschränken Sie nach Einheit in Instanzen mit mehreren Kunden. Rekursiv auf der Stamm-Einheit nur für Inhalte, die für alle gelten.
- Farben mit Bedeutung. Rot heißt aktive Störung, nicht „aufmerksam lesen“.
Bei NexTool behandeln wir die Kommunikation in GLPI als Teil des Betriebs: Wir konfigurieren die richtigen Kanäle, legen eine Ablaufrichtlinie für Hinweise fest und verbinden statische Kommunikation mit dynamischer Benachrichtigung für die Umgebung des Kunden. Wenn Sie über den Banner hinausgehen möchten, deckt Modul Smart Notify die Seite der Techniker ab, und unser Betriebsteam hilft, den vollständigen Ablauf zu gestalten.
Geprüft vom Team von NexTool Solutions.
