Files
MABEA/arbeitskarten/12_eskalation.md
T
patrickandClaude Sonnet 5 fb676a4a0b
CI / backend-tests (push) Successful in 1m6s
CI / frontend-build (push) Successful in 21s
Karte 12: Eskalationslogik für lange offene Fehlbestände
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
2026-09-04 18:04:52 +02:00

23 lines
1.4 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 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 über `GET/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.