10 KiB
Phase 15: Modul-Berechtigungen: Gruppen & User-Grants - Discussion Log
Audit trail only. Do not use as input to planning, research, or execution agents. Decisions are captured in CONTEXT.md — this log preserves the alternatives considered.
Date: 2026-08-04 Phase: 15-modul-berechtigungen-gruppen-user-grants Areas discussed: Grundsatzentscheidungen (vor Roadmap-Eintrag), Sperr-Verhalten im Portal, Standard-Zuweisungen, Admin-UI Ort & Form, AD-Bindung & Sync-Semantik, Nachfragen (Widgets, Löschen, Protokoll)
Grundsatzentscheidungen (vor dem Roadmap-Eintrag geklärt)
Herkunft der Gruppen
| Option | Description | Selected |
|---|---|---|
| Beides: Tessera-Gruppen mit optionaler AD-Bindung | Group-Model mit manuellen Mitgliedern, optional ldapDn — deckt Mandanten mit und ohne AD ab | ✓ |
| Nur Tessera-eigene Gruppen | Ausschließlich im Admin-UI gepflegt, kein memberOf-Sync | |
| Nur AD-Gruppen | Gruppen 1:1 aus dem AD, kein manuelles Anlegen |
User's choice: Tessera-Gruppen mit optionaler AD-Bindung
Default ohne Freigabe
| Option | Description | Selected |
|---|---|---|
| Offen, Einschränkung pro Modul aktivierbar | Ohne Grants sehen alle Nutzer des Mandanten das Modul (heutiges Verhalten) | |
| Geschlossen — Freigabe immer nötig | Tenant-Aktivierung ist nur Voraussetzung, jeder User braucht Grant | ✓ |
User's choice: Geschlossen Notes: Lockout-Risiko wurde benannt; die Migration mit Gruppe „Alle Benutzer" wurde als Gegenmaßnahme vereinbart.
Admin-Bypass
| Option | Description | Selected |
|---|---|---|
| ADMIN + SUPER_ADMIN sehen alles Aktive | Admins umgehen Grants im eigenen Mandanten | ✓ |
| Nur SUPER_ADMIN umgeht | Mandanten-Admins unterliegen selbst den Grants | |
| Niemand umgeht | Grants gelten für alle |
User's choice: ADMIN + SUPER_ADMIN
Tiefe der Berechtigung
| Option | Description | Selected |
|---|---|---|
| Nur Modul-Zugriff (an/aus) | Grant entscheidet nur über Sichtbarkeit und API-Nutzung | ✓ |
| Zugriff + Rechtestufen pro Modul | Zusätzlich read/write/admin je Grant, von jedem Modul auszuwerten |
User's choice: Nur Zugriff an/aus
Sperr-Verhalten im Portal
Direktaufruf einer nicht freigegebenen Modul-URL
| Option | Description | Selected |
|---|---|---|
| 403-Seite mit Hinweis | „Kein Zugriff — wende dich an deinen Administrator" | ✓ |
| Weiterleitung aufs Dashboard | Stiller Redirect ohne Meldung | |
| 404 — Existenz verbergen | Verrät nichts über vorhandene Module, erschwert Support |
User's choice: 403-Seite mit Hinweis
Sichtbarkeit im Marketplace
| Option | Description | Selected |
|---|---|---|
| Sichtbar mit Badge „Kein Zugriff" | Katalog bleibt vollständig, gesperrte Module gekennzeichnet | ✓ |
| Komplett ausblenden | Marketplace zeigt nur Nutzbares | |
| Nur für Admins gefiltert | Gleiche Filterung wie Sidebar, ohne Sonderdarstellung |
User's choice: Sichtbar mit Badge
Wirksamkeit eines Entzugs bei aktiver Session
| Option | Description | Selected |
|---|---|---|
| Beim nächsten Seitenaufruf | API sperrt sofort, Sidebar zieht beim Laden nach | ✓ |
| Sidebar pollt regelmäßig | Entzug wird ohne Reload sichtbar, kostet Extra-Last |
User's choice: Beim nächsten Seitenaufruf
Standard-Zuweisungen
Freigabe-Default beim Aktivieren eines Moduls
| Option | Description | Selected |
|---|---|---|
| Automatisch für „Alle Benutzer" | Aktivieren genügt, Einschränkung nachträglich | |
| Zunächst niemand außer Admins | Jede Freigabe ist ein bewusster zweiter Schritt | |
| Admin wird beim Aktivieren gefragt | Dialog: sofort freigeben oder erst konfigurieren | ✓ |
User's choice: Dialog beim Aktivieren Notes: Der bisher einfache Aktiv-Toggle in /admin/modules bekommt damit eine Rückfrage.
Neu angelegter Benutzer
| Option | Description | Selected |
|---|---|---|
| Ja, automatisch in die Standardgruppe | Neue Benutzer sofort arbeitsfähig | ✓ |
| Nein, ohne Gruppe starten | Admin weist bewusst zu | |
| Checkbox im Anlegen-Formular | Vorbelegt auf ja, abwählbar |
User's choice: Automatisch
Per LDAP importierter Benutzer
| Option | Description | Selected |
|---|---|---|
| Genauso wie manuell angelegte | Eine Regel für beide Herkünfte | ✓ |
| Nur über AD-gebundene Gruppen | Ausschließlich Mitgliedschaften aus dem AD |
User's choice: Genauso wie manuell angelegte
Status der Gruppe „Alle Benutzer"
| Option | Description | Selected |
|---|---|---|
| Geschützte Systemgruppe | Nicht löschbar, nicht umbenennbar | |
| Ganz normale Gruppe | Frei bearbeitbar, umbenennbar, löschbar | ✓ |
User's choice: Normale Gruppe Notes: Diese Wahl warf die Folgefrage auf, wie der Automatismus aus D-11/D-12 sein Ziel findet — beantwortet über die Markierung „Standardgruppe" (D-13).
Admin-UI: Ort & Form
Ort der Gruppenverwaltung
| Option | Description | Selected |
|---|---|---|
| Eigener Punkt /admin/groups | Sechster Eintrag neben den bestehenden Admin-Seiten | ✓ |
| Als Tab in /admin/users | Benutzer und Gruppen auf einer Seite |
User's choice: Eigener Punkt /admin/groups
Ort der Freigabe-Matrix
| Option | Description | Selected |
|---|---|---|
| Eigene Matrix-Seite | Tabelle Module × Gruppen, gesamter Stand auf einen Blick | ✓ |
| Pro Modul in /admin/modules | Aufklappbare Freigabeliste je Modul | |
| Pro Gruppe in der Gruppenverwaltung | Modulliste zum Ankreuzen je Gruppe |
User's choice: Eigene Matrix-Seite
Einzel-Freigaben für Benutzer
| Option | Description | Selected |
|---|---|---|
| Beim Benutzer in /admin/users | Sektion „Zusätzliche Modulfreigaben" plus geerbte Rechte | ✓ |
| In derselben Matrix wie Gruppen | Benutzer als zusätzliche Spalten | |
| Nur über Gruppen — keine Einzelfreigaben | Reduktion des Phasenziels |
User's choice: Beim Benutzer in /admin/users
Ziel des Auto-Beitritts
| Option | Description | Selected |
|---|---|---|
| Markierung „Standardgruppe" | Genau eine Gruppe pro Mandant, umhängbar und abschaltbar | ✓ |
| Fest an den Namen „Alle Benutzer" gebunden | Bricht still beim Umbenennen | |
| Gar kein Automatismus | Widerspricht D-11/D-12 |
User's choice: Markierung „Standardgruppe"
AD-Bindung & Sync-Semantik
Auswahl der AD-Gruppe
| Option | Description | Selected |
|---|---|---|
| Aus dem AD browsen | Bestehende Gruppensuche im LDAP-Service wiederverwenden | ✓ |
| DN manuell eintippen | Einfaches Textfeld, verlangt exakte DN-Kenntnis | |
| Browsen mit manueller Korrektur | Liste plus editierbares Feld |
User's choice: Aus dem AD browsen
Benutzer verlässt die AD-Gruppe
| Option | Description | Selected |
|---|---|---|
| Mitgliedschaft entfernen | Nur die LDAP-Mitgliedschaft fällt weg, manuelle bleiben | ✓ |
| Behalten und markieren | Bleibt bestehen, wird als „nicht mehr im AD" gekennzeichnet |
User's choice: Mitgliedschaft entfernen
Manuelle Mitglieder in gebundenen Gruppen
| Option | Description | Selected |
|---|---|---|
| Ja, beide Quellen nebeneinander | Mitgliedschaft merkt sich Herkunft MANUAL/LDAP | ✓ |
| Nein, gebundene Gruppen sind reine AD-Spiegel | Jede Ausnahme braucht eine zweite Gruppe |
User's choice: Beide Quellen nebeneinander
Zeitpunkt des Gruppen-Syncs
| Option | Description | Selected |
|---|---|---|
| Immer mit dem Benutzer-Sync | memberOf im selben Durchlauf, ein Vorgang | ✓ |
| Eigener Gruppen-Sync-Button | Getrennte Auslösung, zwei Stände |
User's choice: Immer mit dem Benutzer-Sync
Nachfragen: Widgets, Löschen, Protokoll
Widgets gesperrter Module
| Option | Description | Selected |
|---|---|---|
| Nein — außerhalb dieser Phase | Widgets sind heute modulunabhängig, Zuordnung wäre neue Fähigkeit | |
| Ja — Zuordnung mitbauen | Widget-Typen bekommen Modul-Bezug, gesperrte Widgets verschwinden | ✓ |
User's choice: Zuordnung mitbauen Notes: Erweitert die Phase gegenüber den ursprünglichen sechs Success Criteria der Roadmap um Schema, Migration und Dashboard-Logik.
Löschen einer belegten Gruppe
| Option | Description | Selected |
|---|---|---|
| Warnung mit Zahlen, dann kaskadieren | Dialog nennt Mitglieder- und Freigabenanzahl | ✓ |
| Kommentarlos kaskadieren | Ohne Rückfrage | |
| Löschen sperren, solange belegt | Gruppe muss erst geleert werden |
User's choice: Warnung mit Zahlen, dann kaskadieren
Protokollierung von Freigabeänderungen
| Option | Description | Selected |
|---|---|---|
| Ja, in der Datenbank mit Anzeige | Eigene Tabelle, im Admin-UI einsehbar | |
| Nur ins Server-Log | Kein DB-Eintrag, keine UI-Ansicht | ✓ |
| Vorerst gar nicht | Kein Protokoll in dieser Phase |
User's choice: Nur ins Server-Log
Claude's Discretion
- Schema-Details der neuen Modelle (Feldnamen, Indizes, Kaskaden, Erzwingung der Entweder-oder-Beziehung bei ModuleGrant)
- Aufbau und Ort der Zugriffsauflösung im NestJS-Code, inklusive etwaigem Request-Caching
- Migrationstechnik: Prisma-Migration mit Datenschritt oder separates Seed-Skript
- Darstellung der Matrix bei vielen Modulen und Gruppen
- Namensraum und Schnitt der i18n-Keys
- Mechanik der Widget-Typ-→-Modul-Zuordnung (statische Registrierung oder DB-Feld)
Deferred Ideas
- Rechtestufen innerhalb eines Moduls (read/write/admin pro Grant)
- Self-Service „Zugriff anfragen" aus dem Marketplace inklusive Genehmigungsfluss
- Audit-Trail für Berechtigungsänderungen in der Datenbank mit Ansicht im Admin-UI
- Mehrfach-Mandantenzugehörigkeit eines Benutzers (offen seit Phase 2, D-09)