22f748d66c
Deklarix soll ein buchbarer Service werden — dafür muss jede Entität im
Datenmodell über das Frontend steuerbar sein, nicht nur einsehbar.
Schließt drei konkrete Lücken:
- Abteilungen (GET /verwaltung/abteilungen, anlegen/löschen) — ohne
diese Seite blieb die Abteilung-Auswahl im Antrag-Fragebogen leer
und unbenutzbar, das war ein Funktionsdefizit, kein Komfortfehler.
- Eigene Werkzeug-Sperrungen (GET /verwaltung/werkzeuge) — ein Mandant
kann einen zentralen Katalogeintrag jetzt für sich sperren/entsperren,
ohne den zentralen Katalog selbst zu verändern.
- Nutzer-Deaktivierung (POST /verwaltung/nutzer/{id}/deaktivieren bzw.
.../aktivieren, neue Spalte app_user.active, Migration 0012). Nutzer
werden nicht gelöscht (Fremdschlüssel auf antrag/entscheidung/
audit_log würden das verhindern und die Historie zerstören) —
deaktivierte Logins können sich nicht mehr anmelden und verlieren
eine laufende Sitzung sofort. Ein Admin kann sich nicht selbst
deaktivieren.
Zusätzlich: store.ListAktiveGenehmigungenForAccount als Grundlage für
die Wiedervorlage (Schritt 7, Web-Layer folgt).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
8 lines
487 B
SQL
8 lines
487 B
SQL
-- Nutzer können nicht gelöscht werden (app_user wird von antrag,
|
|
-- session, bewertung [über antrag], entscheidung, audit_log,
|
|
-- registereintrag [über antrag] per Foreign Key referenziert — ein
|
|
-- Hard-Delete würde die Historie zerstören). Stattdessen: deaktivieren.
|
|
-- Ein deaktivierter Nutzer kann sich nicht mehr anmelden, bleibt aber
|
|
-- als Akteur in Anträgen/Entscheidungen/Audit-Log nachvollziehbar.
|
|
ALTER TABLE app_user ADD COLUMN active BOOLEAN NOT NULL DEFAULT true;
|