scripte/MABEA
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Karte 12: Eskalationslogik für lange offene Fehlbestände
CI / backend-tests (push) Successful in 1m6s
Details
CI / frontend-build (push) Successful in 21s
Details

Browse Source 
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
This commit is contained in:
patrick
2026-09-04 18:04:52 +02:00
co-authored by Claude Sonnet 5
parent 7f06d1cecc
commit fb676a4a0b
12 changed files with 340 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
arbeitskarten/12_eskalation.md
+5
View File
@@ -15,3 +15,8 @@ Zeitschwellen konfigurierbar, nicht fix.
## 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.