Verwaltung · Stand 2.6.2026
Rechte und Audit-Log
Sichtbar nur für fscs_admin. Top-Tab Admin.
Permission-Matrix (/admin/rechte/)
Zeigt Rolle × Permission. Permissions sind in Gruppen gegliedert (Anfragen, Angebote, Beratung, Tickets, Mandanten, Dokumente, System, Mein Mandant).
Sonderregel: fscs_admin hat immer alle Permissions —
unabhängig davon, was die Matrix anzeigt. Die Matrix wirkt
ausschließlich auf die anderen Rollen.
Default-Konfiguration
Bei jedem Container-Start läuft ensure_default_permissions. Das
seedet nur fehlende Einträge nach (additiv, manuelle
Konfiguration bleibt unangetastet). Defaults siehe Code-Katalog in
backend/app/permissions.py::ALL_PERMISSIONS.
Reset
Button „Defaults wiederherstellen” im UI legt die Default- Einträge nach. Bestehende Einträge bleiben.
User-spezifische Permissions (/admin/benutzer/?id=…)
Im Benutzer-Detail unten: User-Permissions. Sind
zusätzlich zu den Rollen-Permissions — additiv, nicht
abziehend. Beispiel: ein fscs_bearbeiter bekommt einmalig
rechte_verwalten für einen konkreten Auftrag.
Audit-Log (/admin/audit/)
Read-only-UI. Zeigt die letzten 200 Einträge mit:
- Zeitpunkt
- Aktor (User-ID + Name; bei System-Aktionen
NULL) - Aktion (z. B.
login_failed,mandant_user_invited,ticket_status_change,user_hard_delete) - Ziel-Typ + Ziel-ID
- Payload (JSON)
- IP-Hash
Was ins Audit-Log kommt
Alle schreibenden Admin- und Auth-Endpoints schreiben Audit-Spuren. Beispiele:
- Login (erfolgreich/fehlgeschlagen), Logout
- Passwort-/E-Mail-Wechsel, MFA on/off
- User-Create/Update/Deactivate/HardDelete
- Mandant-Create/Update
- Ticket-Status-/Priority-/Due-Changes
- Dokument-Version-Upload/Edit/Delete
Lese-Operationen werden NICHT geloggt (DSGVO-Datensparsamkeit).
Pseudonymisierung
Nach Hard-Delete eines Users wird actor_user_id in allen seinen
Audit-Einträgen auf NULL gesetzt — Trail bleibt erhalten, Aktor-
Identität ist anonymisiert.