Betrieb · Stand 2.6.2026
Cron-Jobs und Benachrichtigungen
Alle Cron-Jobs laufen auf fsxprojekte und rufen per
docker exec ins API-Container-Modul app.tools.*. Setup-Doku:
Dokumentation/Cron-Setup.md.
Cron-Plan
| Cron | Job | Wirkung |
|---|---|---|
*/10 * * * * | check-burst-downloads | Burst-Alarm bei > 20 Downloads / 10 Min / Mandant + Download-Log-Pseudonymisierung ab 12 Monate |
*/30 * * * * | check-due | Eskalations-Mail bei due_at-Unterschreitung; Throttle 12 h/Ticket |
*/30 * * * * | check-data-breach-deadline | Warnung bei < 12 h zur 72-h-Frist (Art. 33 DSGVO); pro Ticket nur einmal |
17 7 * * * | check-ticket-aging | Reminder bei Vorgängen ≥ 14 Tage ohne Aktivität; Throttle 14 Tage/Ticket |
0 7 * * 1 | check-stammdaten-digest | Wochenbericht Mo 7:00: Mandanten ohne Kontakt-E-Mail oder Anschrift |
Idempotenz
Jeder Job, der eine Mail auslösen könnte, prüft vorher das Audit-Log:
ticket.data_breach_deadline_warned→ einmal warnen pro Ticketticket.aging_reminded→ max. 1 Mail / 14 Tage- Burst-Alarm: in-memory throttle, max. 1 Alarm / 4 h / Mandant
Das heißt: Cron darf beliebig oft laufen, ohne Mail-Wellen auszulösen.
Event-getriggerte Notifications
Zusätzlich werden bei Aktionen sofort Mails verschickt:
| Event | Empfänger | Trigger |
|---|---|---|
user_invited | Einladender + FS/CS | mandanten.py invite_user + rbac.py create_user |
invitation_accepted | Einladender + FS/CS | auth.py accept_invitation |
password_changed | User + FS/CS | auth.py change_password |
email_changed | alte + neue Adresse + FS/CS | auth.py confirm_email_change |
mfa_changed | User + FS/CS | auth.py mfa_verify_setup und mfa_disable |
data_breach_created | FS/CS sofort | portal.py create_ticket mit typ="datenpanne" |
role_changed | User + FS/CS | rbac.py update_user bei Rollenwechsel |
user_deactivated | User + FS/CS | rbac.py update_user is_active=False + deactivate_user |
login_failure_burst | User + FS/CS | auth.py login bei genau 5 fails / 60 min |
new_download | mandant_admin + FS/CS | dokumente_admin.py upload_version bei Erst-Veröffentlichung |
Persönliche Notification-History
Jeder User sieht in /profil/ eine Liste aller empfangenen
Benachrichtigungs-Mails (Tabelle notification, Spalten:
event_typ, subject, body_preview, related_url, at, read_at). Auto-
Logging beim Versand, wenn die Empfänger-Adresse einem User-Konto
entspricht. Sammelpostfach-Adressen (notify_recipient) ohne User-
Konto werden NICHT persönlich geloggt.
API: /api/me/notifications (eigener Scope), /unread-count,
PATCH /{id} (mark read), POST /mark-all-read.
Fehlerfälle
- SMTP-Versand schlägt fehl → Job/Endpoint blockiert nicht; der
Fehler landet im API-Container-Log mit
logger.exception(...). Empfänger-Mail wird nicht erzeugt; Audit-Log-Eintrag wurde aber schon geschrieben (Konsistenz: was passiert ist, ist dokumentiert). - DB-Persistenz der Notification-History schlägt fehl → Mail geht trotzdem raus; der DB-Fehler landet im Log.