BU-06 – Benutzer deaktivieren / reaktivieren
Stand: 12.10.2026 11:23
Branch: main
Status: erster Vorschlag
Änderungshistorie anzeigen
Use Case: UC08 – Benutzerverwaltung
Screen: BU-06
Wireframe
Zum Vergrössern auf das Bild klicken; es öffnet sich in voller Grösse.
1. Zweck
BU-06 dient zur kontrollierten Deaktivierung oder Reaktivierung eines Benutzers innerhalb eines Tenants.
Der Screen stellt sicher, dass Benutzer nicht versehentlich gesperrt oder wieder aktiviert werden. Besonders wichtig ist der Schutz vor der Deaktivierung des letzten aktiven tenant_admin.
2. Primäre Nutzer
| Rolle |
Nutzung |
tenant_admin |
deaktiviert oder reaktiviert Benutzer im eigenen Tenant |
mitarbeiter |
keine Berechtigung zur Deaktivierung / Reaktivierung |
kunde |
keine Nutzung dieser internen Ansicht |
superadmin |
nicht Zielnutzer dieses Screens |
3. Einstieg / Auslöser
| Einstieg |
Beschreibung |
| BU-01 |
Aktion aus Benutzerliste |
| BU-03 |
Aktion aus Benutzerprofil |
| BU-08 |
Prüfung nach Audit-Eintrag, keine direkte Änderung |
4.1 Kontext
| Feld |
Beschreibung |
| Benutzer |
Name und E-Mail |
| Tenant |
betroffene Tauchschule / Organisation |
| aktuelle Rolle |
z. B. mitarbeiter oder tenant_admin |
| aktueller Status |
active oder inactive |
| letzter Login |
Kontextinformation |
| letzter Admin-Schutz |
Warnhinweis, falls relevant |
4.2 Statuswechsel
| Feld |
Beschreibung |
Pflicht |
| Aktion |
deaktivieren oder reaktivieren |
Ja |
| neuer Status |
inactive oder active |
Ja |
| Grund |
Pflicht bei Deaktivierung, empfohlen bei Reaktivierung |
abhängig |
| Bemerkung |
optionale Zusatznotiz |
Nein |
| Bestätigung |
bewusste Bestätigung vor Speicherung |
Ja |
5. Eingaben / Aktionen
| Aktion |
Beschreibung |
| Benutzer deaktivieren |
setzt Status auf inactive |
| Benutzer reaktivieren |
setzt Status auf active |
| Grund erfassen |
Pflicht bei Deaktivierung |
| Bestätigen |
speichert Statuswechsel und Audit-Eintrag |
| Abbrechen |
zurück zu BU-03 oder BU-01 |
6. Validierungen / Regeln
| ID |
Regel |
| BU06-R01 |
Nur tenant_admin darf Benutzer deaktivieren oder reaktivieren |
| BU06-R02 |
Statuswechsel gilt nur innerhalb des eigenen Tenants |
| BU06-R03 |
superadmin darf nicht durch Tenant deaktiviert werden |
| BU06-R04 |
Es muss immer mindestens ein aktiver tenant_admin verbleiben |
| BU06-R05 |
Der letzte aktive tenant_admin darf nicht deaktiviert werden |
| BU06-R06 |
Deaktivierung benötigt Pflichtgrund |
| BU06-R07 |
Reaktivierung sollte auditierbar begründet werden können |
| BU06-R08 |
Deaktivierte Benutzer dürfen sich nicht anmelden |
| BU06-R09 |
Reaktivierte Benutzer erhalten ihre Tenant-Rolle zurück, sofern nicht separat geändert |
| BU06-R10 |
Statuswechsel muss auditierbar sein |
7. Status- und Fehlermeldungen
| Situation |
Meldung / Darstellung |
| letzter aktiver Admin |
„Dieser Benutzer ist der letzte aktive Tenant-Admin und kann nicht deaktiviert werden.“ |
| Pflichtgrund fehlt |
„Bitte Grund für die Deaktivierung erfassen.“ |
| Benutzer bereits inaktiv |
„Benutzer ist bereits deaktiviert.“ |
| Benutzer bereits aktiv |
„Benutzer ist bereits aktiv.“ |
| fremder Tenant |
„Zugriff verweigert.“ |
| erfolgreich deaktiviert |
„Benutzer wurde deaktiviert.“ |
| erfolgreich reaktiviert |
„Benutzer wurde reaktiviert.“ |
8. Bezug zu Datenmodell
| Bereich |
Bezug |
| Benutzer |
users |
| Tenant-Zuordnung |
tenant_users |
| Status |
tenant_users.status |
| Deaktivierung |
deactivated_at, deactivated_by, deactivation_reason |
| Reaktivierung |
reactivated_at, reactivated_by, optionaler Grund |
| Audit |
audit_log |
9. Sicherheits- und Audit-Bezug
| Thema |
Umsetzung |
| Tenant-Isolation |
serverseitig erzwingen |
| letzter Admin-Schutz |
technisch erzwingen und im UI anzeigen |
| Pflichtgrund |
bei Deaktivierung zwingend |
| Login-Sperre |
deaktivierte Benutzer können sich nicht anmelden |
| Audit |
alter Status, neuer Status, Grund, Benutzer, Zeitpunkt |
10. Akzeptanzkriterien
| ID |
Kriterium |
| BU06-AC01 |
tenant_admin kann BU-06 aus BU-03 öffnen |
| BU06-AC02 |
System zeigt Benutzer, Rolle und aktuellen Status |
| BU06-AC03 |
System verhindert Deaktivierung des letzten aktiven tenant_admins |
| BU06-AC04 |
Deaktivierung benötigt Pflichtgrund |
| BU06-AC05 |
Statuswechsel wird erst nach Bestätigung gespeichert |
| BU06-AC06 |
deaktivierte Benutzer können sich nicht anmelden |
| BU06-AC07 |
Reaktivierung setzt Status wieder auf active |
| BU06-AC08 |
Statuswechsel wird auditierbar protokolliert |
| BU06-AC09 |
Benutzer fremder Tenants können nicht geändert werden |
11. Offene Punkte
| ID |
Frage |
Status |
| BU06-O01 |
Muss Reaktivierung ebenfalls einen Pflichtgrund haben? |
Vorschlag: empfohlen, aber nicht zwingend V1 |
| BU06-O02 |
Wird eine aktive Session bei Deaktivierung sofort beendet? |
Security-Detail offen, Empfehlung: Ja |
| BU06-O03 |
Werden Kundenbenutzer in BU-06 deaktiviert oder über UC06? |
offen, Bezug zu UC06 |
| BU06-O04 |
Darf ein tenant_admin sich selbst deaktivieren? |
Vorschlag: Nein, wenn letzter Admin-Schutz betroffen; generell prüfen |
Änderungshistorie
| Datum, Uhrzeit |
Version |
Änderung |
Autor |
| 12.10.2026 11:23 |
1.3 |
Abschnitt «Wireframe» mit klickbarem Bild des Screens ergänzt |
Claude |
| 12.10.2026 09:58 |
1.2 |
Änderungshistorie ans Dokumentende verschoben und Sprunglink «Änderungshistorie anzeigen» unter dem Kopf ergänzt (einheitlicher Dokumentaufbau gemäss AGENTS.md) |
Claude |
| 12.10.2026 09:08 |
1.1 |
Branch-Angabe im Kopfbereich auf main korrigiert |
Claude |
| 01.08.2026 14:55 |
1.0 |
Kopfbereich vereinheitlicht |
David Mittig |