docs(roadmap): add Phase 16 AD group synchronisation
This commit is contained in:
@@ -34,6 +34,7 @@ Decimal phases appear between their surrounding integers in numeric order.
|
|||||||
- [ ] **Phase 13: Scraping Adapters & Cross-Source Deduplication** - AI-AG NetServer + cosinex adapters with fuzzy cross-source dedup and a hard denylist for banned portals
|
- [ ] **Phase 13: Scraping Adapters & Cross-Source Deduplication** - AI-AG NetServer + cosinex adapters with fuzzy cross-source dedup and a hard denylist for banned portals
|
||||||
- [ ] **Phase 14: RSS, Email-Alert Ingestion & Module Rollout** - RSS + email-alert long tail, admin source/mailbox config, excluded-portal transparency, i18n
|
- [ ] **Phase 14: RSS, Email-Alert Ingestion & Module Rollout** - RSS + email-alert long tail, admin source/mailbox config, excluded-portal transparency, i18n
|
||||||
- [ ] **Phase 15: Modul-Berechtigungen: Gruppen & User-Grants** - Modulzugriff pro Gruppe und pro Benutzer zusätzlich zur Mandanten-Aktivierung, Gruppen mit optionaler AD-Bindung
|
- [ ] **Phase 15: Modul-Berechtigungen: Gruppen & User-Grants** - Modulzugriff pro Gruppe und pro Benutzer zusätzlich zur Mandanten-Aktivierung, Gruppen mit optionaler AD-Bindung
|
||||||
|
- [ ] **Phase 16: AD-Gruppen-Synchronisation** - Ausgewählte AD-Gruppen werden als Tessera-Gruppen übernommen und in Name, Bestand und Mitgliedschaft nachgeführt
|
||||||
|
|
||||||
## Phase Details
|
## Phase Details
|
||||||
|
|
||||||
@@ -538,6 +539,37 @@ Plans:
|
|||||||
|
|
||||||
**UI hint**: yes
|
**UI hint**: yes
|
||||||
|
|
||||||
|
### Phase 16: AD-Gruppen-Synchronisation
|
||||||
|
|
||||||
|
**Goal:** Ausgewählte AD-Gruppen werden als Tessera-Gruppen angelegt und dauerhaft nachgeführt, statt jede Gruppe von Hand anzulegen und zu binden. Der Admin wählt aus der AD-Gruppenliste aus, welche Gruppen übernommen werden; der bestehende Benutzer-Sync hält Bestand, Namen und Mitgliedschaften danach aktuell.
|
||||||
|
**Depends on**: Phase 15
|
||||||
|
**Requirements**: TBD (werden in /gsd-plan-phase 16 vergeben)
|
||||||
|
**Success Criteria** (what must be TRUE):
|
||||||
|
|
||||||
|
1. Ein Admin wählt aus der AD-Gruppenliste einzelne Gruppen zur Übernahme aus; für jede ausgewählte Gruppe entsteht eine Tessera-Gruppe mit gesetzter AD-Bindung
|
||||||
|
2. Nicht ausgewählte AD-Gruppen werden nicht angelegt — es gibt keine pauschale Übernahme einer ganzen OU
|
||||||
|
3. Wird eine übernommene Gruppe im AD umbenannt, zieht der Name der Tessera-Gruppe beim nächsten Sync nach
|
||||||
|
4. Verschwindet eine übernommene Gruppe aus dem AD, wird die Tessera-Gruppe samt ihrer Mitgliedschaften und Modulfreigaben entfernt
|
||||||
|
5. Manuell angelegte Gruppen ohne AD-Bindung bleiben vom Gruppen-Sync unberührt
|
||||||
|
|
||||||
|
**Design-Entscheidungen** (mit User geklärt am 2026-08-05):
|
||||||
|
|
||||||
|
- Umfang: nur ausdrücklich ausgewählte AD-Gruppen, keine OU-weite Automatik
|
||||||
|
- Löschen im AD löscht die Tessera-Gruppe mit — inklusive der daran hängenden Modulfreigaben
|
||||||
|
- Umbenennen im AD zieht in Tessera nach
|
||||||
|
|
||||||
|
**Bekannte Folge, bewusst akzeptiert**: Ein Löschvorgang im AD nimmt betroffenen Benutzern schlagartig die über diese Gruppe vergebenen Modulzugriffe, ohne den Warndialog aus D-17 zu durchlaufen — der greift nur beim Löschen über die Tessera-Oberfläche.
|
||||||
|
|
||||||
|
**Offen für die Planung**: ob ein Admin eine automatisch angelegte Gruppe in Tessera umbenennen darf (würde beim nächsten Sync überschrieben), und wie sich die Auswahl-Oberfläche zur bestehenden AD-Gruppenauswahl in `/admin/groups` verhält.
|
||||||
|
|
||||||
|
**Plans**: 0 plans
|
||||||
|
|
||||||
|
Plans:
|
||||||
|
|
||||||
|
- [ ] TBD (run /gsd-plan-phase 16 to break down)
|
||||||
|
|
||||||
|
**UI hint**: yes
|
||||||
|
|
||||||
## Progress
|
## Progress
|
||||||
|
|
||||||
**Execution Order:**
|
**Execution Order:**
|
||||||
|
|||||||
Reference in New Issue
Block a user