Handbuch
← Zurück zur Handbuch-Übersicht
Verwaltung · Stand 20.10.2026
Benachrichtigungs-Kanäle (fachlich / technisch)
Automatische Mails aus xDSB.eu laufen seit 2026-10-08 über genau zwei
Sammelpostfächer — kein Fan-out mehr an einzelne FSCS-Konten. Beide
Adressen werden im Admin gepflegt unter
Admin → Benachrichtigungen (/admin/benachrichtigungen/,
Rolle fscs_admin).
Die zwei Kanäle
| Kanal | Zweck | Was wird dort hingesendet |
|---|---|---|
| fachlich | Alles, worauf jemand im Tagesgeschäft reagieren muss | Vorgangs-Events (notify_ticket_event FSCS-Seite), Datenpanne eröffnet / 72-h-Frist-Warnung, Ticket-Aging-Reminder, neuer Download veröffentlicht, Wochenbericht Stammdaten-Lücken |
| technisch | Admin-Housekeeping ohne direkten Handlungsbedarf | Einladungen verschickt / angenommen, Passwort geändert, Login-E-Mail geändert, 2FA aktiviert/deaktiviert, Rolle geändert, Konto deaktiviert, Login-Burst-Warnung |
Beide Adressen können identisch sein — die Trennung dient primär der
Postfach-/Filter-Ordnung auf Empfängerseite. In vielen Setups bleibt
xdsb@xdsb.eu für beide der sinnvolle Default.
Adressen setzen
- Als
fscs_admineinloggen. - Zu Admin → Benachrichtigungen navigieren.
- Zwei Felder: Fachlich und Technisch / administrativ. Beides Pflicht-Felder — ein leeres Feld wäre ein stiller Alle-Mails-aus- Zustand, deshalb hart abgelehnt.
- „Speichern“ → Audit-Log-Eintrag
notify_recipients_changed.
Unter jedem Feld zeigt ein Hinweis, ob der Wert aus der DB oder noch
aus dem Env-Default (SETTINGS.notify_recipient) stammt.
Fallback
Fehlt ein DB-Eintrag (frisches Deployment, noch nie gespeichert),
greift der Env-Default SETTINGS.notify_recipient aus
/opt/xdsb.eu/.env. Dadurch arbeitet jedes bestehende Deployment ohne
Admin-Pflege sofort weiter — die beiden Kanäle gehen dann beide an die
Env-Adresse.
Was NICHT über die Kanäle läuft
Diese Mails bleiben unverändert direkt an die betroffene Person:
- Magic-Login-Links, Einladungs-Links, Passwort-Reset-Links
- Mandanten-Benachrichtigung bei neuen Vorgangs-Events auf
Portal-Seite (die laufen über den Mandanten-Verteiler aus
_build_mandant_recipients) - Direkte Nutzer-Benachrichtigungen (z. B. „Ihre 2FA wurde aktiviert“ — geht primär an den User, nur die Audit-Kopie geht zusätzlich an den technischen Kanal)
Historie
Vor dem Umbau fuhr xDSB ein Fan-out-Modell: Jede automatische Mail
ging an SETTINGS.notify_recipient und zusätzlich an jedes
aktive fscs_admin-Konto persönlich mit Magic-Login-Link. Bei einer
Einladung landeten so drei bis vier Mails pro Ereignis in verschiedenen
Postfächern — operativ unübersichtlich, besonders bei
Housekeeping-Events ohne Handlungsbedarf.
Siehe Commits eff5c80 (Einladungen zuerst entschärft) und d7f6d18
(Zwei-Kanal-Modell mit UI). Die alten Helfer
_build_fscs_recipients und _send_to_internal sind seitdem aus
notifications.py entfernt.