- Let the user mark closed tickets as really done and hide them, so tickets closed prematurely by an agent stay visible until confirmed - User-side "archived" flag stored in the DB (independent of Zammad), added via a schema migration on existing databases - Hide archived tickets from the overview by default with an "erledigte einblenden" toggle; archive/unarchive from the ticket detail page and via a per-row quick action - Poller automatically un-hides an archived ticket when new activity is detected, so nothing is missed Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
EPI-Support Monitor
Interne Überwachungs- und Auswertungsplattform für die Tickets auf
epi-helpdesk.zammad.com. Die Anwendung ruft regelmäßig alle sichtbaren Tickets
über die Zammad-API ab, vergleicht sie mit dem letzten Stand und protokolliert
Änderungen durch die Support-Agenten (Status, Bearbeiter, Priorität,
Schließung, neue Antworten). Optional gibt es E-Mail-Alerts.
Das interne Dashboard bietet:
- Übersicht – alle Tickets mit Statusfilter und „ungelesene Änderungen“
- Änderungs-Verlauf – Feed + Timeline pro Ticket (wer/was/wann geändert)
- Auswertung – KPIs (Aufkommen, offen/geschlossen, eskaliert), Median/Ø/P90 von Reaktions- und Lösungszeit, Zeitverlauf pro Monat (SVG-Diagramm) sowie Verteilungen nach Status, Priorität, Gruppe und Agent; Zeitraumfilter (30/90/180/365 Tage/gesamt)
- Excel-Export – komplette Auswertung als
.xlsx(KPIs, Verteilungen, Monatswerte, Tickets, Änderungen) - Konversation lesen – vollständiger Nachrichtenverlauf je Ticket (Absenderrolle, Datum, Text). HTML wird sicher zu Text bereinigt – keine nachgeladenen Bilder/Tracking, kein eingebetteter Schadcode.
- Antworten & neue Tickets – direkt aus der Plattform an EPI; jede
Schreibaktion läuft über eine Bestätigungsseite (Schutz vor
versehentlichem Senden). Schreibzugriff nutzt CSRF (Session) bzw. den
ZAMMAD_TOKEN.
Hinweis zum Versand: Der Sende-Pfad (
create_article/create_ticket, Artikeltypweb) ist gebaut und geprüft, aber bewusst nicht live getestet, um keine echten Nachrichten an EPI auszulösen. Der erste echte Versand sollte kontrolliert erfolgen; sollte EPI den Artikeltyp ablehnen, ggf. aufnoteumstellen (inapp/zammad.py).
Da auf der Zammad-Instanz „API password access" deaktiviert ist, meldet sich
die App per Session-Login an (wie der Browser). Sobald ein persönlicher
API-Token verfügbar ist, einfach ZAMMAD_TOKEN in der .env setzen – dann
wird der Token bevorzugt verwendet.
Architektur
| Komponente | Aufgabe |
|---|---|
episupport-poller (systemd) |
Hintergrund-Abruf alle POLL_INTERVAL_SECONDS, Änderungserkennung, E-Mail |
episupport-web (systemd, gunicorn) |
Flask-Dashboard auf 127.0.0.1:8071 |
Apache conf-available/episupport.conf |
Reverse-Proxy srhnweb/episupport → gunicorn |
data/episupport.db (SQLite, WAL) |
Ticket-Snapshots, Änderungs-Log, Abrufprotokoll |
Deployment auf SRHNWEB
# 1. Dateien auf den Server bringen, Zielordner /var/www/html/episupport
# (z. B. per scp/rsync/git)
# 2. Setup ausführen
sudo bash /var/www/html/episupport/deploy/setup.sh
# 3. Zugangsdaten eintragen
sudo nano /var/www/html/episupport/.env # ZAMMAD_USER / ZAMMAD_PASSWORD
sudo systemctl restart episupport-poller episupport-web
Danach erreichbar unter http(s)://srhnweb/episupport.
Updates einspielen
Neue Dateien nach /var/www/html/episupport kopieren, dann erneut
sudo bash deploy/setup.sh (installiert Abhängigkeiten neu und startet Dienste).
Konfiguration (.env)
Siehe .env.example. Wichtig: ZAMMAD_USER/ZAMMAD_PASSWORD oder
ZAMMAD_TOKEN. E-Mail-Benachrichtigung über NOTIFY_ENABLED=true + SMTP-Daten.
Lokaler Test (Entwicklung)
python -m venv venv && venv/bin/pip install -r requirements.txt
cp .env.example .env # ausfüllen
venv/bin/python run_poller.py # einmal laufen lassen -> Basis-Snapshot
venv/bin/python wsgi.py # Dashboard auf http://127.0.0.1:8071/episupport
Logs
journalctl -u episupport-poller -f
journalctl -u episupport-web -f
Sicherheit
.enventhält Zugangsdaten → Rechte 640, nicht ins Git committen (.gitignore).- Zugriff aufs Dashboard ggf. in
episupport-apache.confperRequire ipaufs interne Netz beschränken. - Für den Dauerbetrieb einen eigenen, einzeln widerrufbaren API-Token statt des Passworts verwenden.