patrickandClaude Sonnet 5
b33d1c83a9
Atomare Aus+Ein-Buchung in einer Materialbewegung-Zeile statt zwei Einzelschritten. NOTIF-001 war bereits produktiv umgesetzt, Backlog war nur veraltet - korrigiert. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CVgbozhYmuEhiEJHffRXCV
3.8 KiB
Epic 18 — Notifications & Eskalation
Details zu NOTIF-001 … NOTIF-002 (vollständig). Übernommen aus arbeitskarten/05_benachrichtigungen.md
und arbeitskarten/12_eskalation.md (Karte 05+12) — beide Karten hatten kein Gegenstück im
ursprünglichen 16-Epic-Backlog, obwohl Karte 12 bereits vollständig implementiert ist.
NOTIF-001 — Benachrichtigung bei neuem Fehlbestand
- Ziel: Verantwortlicher erfährt zeitnah von neuem Fehlbestand, ohne aktiv nachschauen zu müssen.
- Beschreibung: Zwei Kanäle: Dashboard-Anzeige (Portal) und E-Mail. Kein Push/App in V1.
- Benutzerwert: Kein Fehlbestand geht unbemerkt unter.
- Abhängigkeiten: INV-006, FOUND-002
- Datenmodell: keins zusätzlich (E-Mail-Versand ist zustandslos, triggert bei Statuswechsel "offen")
- Backend: E-Mail-Versand-Komponente, Trigger bei Fehlbestand-Entstehung
- Frontend: Dashboard-Kachel (Pflichtbestandteil)
- Mobile: Dashboard-Ansicht
- QR-Code/Seriennummer/Inventarnummer: nein
- Akte: nein direkt
- Rechte: Verantwortliche erhalten Benachrichtigung für ihre Zuständigkeit
- Audit: Versand nicht zwingend geloggt (kein fachlicher Vorgang, nur Benachrichtigung)
- Akzeptanzkriterien: neuer Fehlbestand löst E-Mail an zuständigen Verantwortlichen aus und erscheint im Dashboard.
- Tests: Trigger-Test (Fehlbestand-Entstehung → E-Mail-Mock aufgerufen).
- DoD: deckt sich 1:1 mit MABEA — bereits vollständig umgesetzt und produktiv
(
app/services/benachrichtigung.py, ausgelöst inkontrolle/erfassung.pyundgeraet_instanz.pybei jeder Fehlbestand-Entstehung, Test intest_email.py).
NOTIF-002 — Eskalation lange offener Fehlbestände
- Ziel: Automatische Eskalation, wenn ein Fehlbestand zu lange offen bleibt.
- Beschreibung: Zwei Stufen — Erinnerung an Materialverantwortliche nach X Tagen, Eskalation an Leitungsverantwortliche/Administration nach Y Tagen. Zeitschwellen konfigurierbar, nicht fix im Code.
- Benutzerwert: Verschleppte Fehlbestände werden nicht endlos ignoriert.
- Abhängigkeiten: INV-006, NOTIF-001
- Datenmodell:
eskalation_konfiguration(Singleton-Zeile, Zeitschwellen je Stufe), Tracking-Zeitstempel je Stufe anfehlbestand(verhindert Mehrfachversand) - Backend:
app/services/eskalation.py(zweistufige Logik),GET/PUT /api/v1/eskalation/konfiguration(admin-editierbar),POST /api/v1/eskalation/pruefen(admin-only, Prüflauf anstoßen) - Frontend: Admin-UI zur Konfiguration + manueller "Jetzt prüfen"-Trigger
- Mobile: nein
- QR-Code/Seriennummer/Inventarnummer: nein
- Akte: nein direkt
- Rechte: Konfiguration/manueller Prüflauf: Administrator
- Audit: Eskalationsversand nachvollziehbar über Tracking-Zeitstempel
- Akzeptanzkriterien: Fehlbestand über Schwelle X löst Erinnerung aus, über Schwelle Y Eskalation, kein Mehrfachversand derselben Stufe.
- Tests: Schwellenwert-Tests (genau an der Grenze), Mehrfachversand-Schutz-Test.
- DoD: deckt sich 1:1 mit MABEA — bereits vollständig umgesetzt und produktiv.
Scheduling (Cron) ist Betriebsaufgabe, kein eigener Scheduler-Prozess im Code — auf
dem Zielserver per systemd-Timer (
mabea-eskalation.timer), der den Prüf-Endpunkt periodisch aufruft.
MABEA-Ist-Stand-Abgleich (korrigiert 2026-09-06): NOTIF-001 und NOTIF-002 sind
BEIDE vollständig umgesetzt und produktiv. Die zuvor hier dokumentierte Lücke bei
NOTIF-001 war veraltet — E-Mail-Versand bei Fehlbestand-Entstehung existiert bereits
seit Sprint 6 (app/services/benachrichtigung.py). Diese Epic-Datei existierte bislang
nicht — reine Nachdokumentation, keine offene Lücke mehr.
Referenzen
Alte Arbeitskarten (übernommen, Karten-Dateien gelöscht): Karte 05 Benachrichtigungen, Karte 12 Eskalation offener Fehlbestände.