# 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)