patrickandClaude Sonnet 5
fb676a4a0b
Zwei Stufen (Erinnerung an Materialverantwortliche, Eskalation an Leitungsverantwortliche/Administration) mit Tracking-Zeitstempel je Stufe gegen Mehrfachversand. Zeitschwellen in eskalation_konfiguration (DB, Singleton), admin-editierbar über GET/PUT /eskalation/konfiguration - bewusst nicht fix im Code. Prüflauf per POST /eskalation/pruefen angestoßen, Scheduling (Cron/systemd-Timer) bleibt Betriebsaufgabe. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CVgbozhYmuEhiEJHffRXCV
1.4 KiB
1.4 KiB
Karte 12 – Eskalation offener Fehlbestände
Status: Roadmap-Feature, Datenmodell-Vorbereitung schon in V1 sinnvoll
Entscheidung
Später gewünscht: automatische Eskalation bei lange offenen Fehlbeständen, z. B.:
- Erinnerung nach X Tagen (🟡)
- Eskalation an Leitungsverantwortlichen nach Y Tagen (🔴)
Zeitschwellen konfigurierbar, nicht fix.
Konsequenz für V1
- Prompt 03 (Fehlbestandsmanagement): Fehlbestand-Entität muss Zeitstempel "entstanden am" führen, damit "Alter" später berechenbar ist, ohne Modelländerung.
- Kein Eskalationsmechanismus selbst in V1/MVP (Prompt 18) – nur Datenbasis dafür vorhalten.
Umsetzung
- Eskalationslogik (Jobs, Schwellenwerte, Empfängerlogik) → Prompt 24 (Roadmap).
Umsetzungsstand (2026-09-04)
app/services/eskalation.py: zwei Stufen (Erinnerung an Materialverantwortliche, Eskalation an Leitungsverantwortliche/Administration), Tracking-Zeitstempel je Stufe verhindert Mehrfachversand.- Zeitschwellen in
eskalation_konfiguration(DB, Singleton-Zeile) statt fix im Code - admin-editierbar überGET/PUT /api/v1/eskalation/konfiguration. - Prüflauf selbst per
POST /api/v1/eskalation/pruefen(admin-only) angestoßen - Scheduling (Cron) ist weiterhin Betriebsaufgabe, kein eigener Scheduler-Prozess im Code (Prompt 19 Deployment-Regel). Auf dem Zielserver z. B. per systemd-Timer/Cron, der diesen Endpunkt periodisch mit Admin-Token aufruft.