docs(roadmap): add Phase 15 module permissions (groups & user grants)
Two-level module access: tenant activation stays a prerequisite, plus new per-group and per-user grants. Records the four design decisions taken with the user: Tessera-owned groups with optional AD binding, closed-by-default access, ADMIN/SUPER_ADMIN bypass within their tenant, and access on/off only (no permission levels inside modules). Starts milestone v1.2. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
+35
-1
@@ -8,6 +8,7 @@ Tessera delivers a modular portal platform where tenants activate workflow modul
|
||||
|
||||
- ✅ **v1.0 MVP** - Phases 1-9 (shipped 2026-07-02)
|
||||
- 🚧 **v1.1 Ausschreibungs-Radar** - Phases 10-14 (in progress)
|
||||
- 🚧 **v1.2 Plattform-Berechtigungen** - Phase 15+ (in progress)
|
||||
|
||||
## Phases
|
||||
|
||||
@@ -32,6 +33,7 @@ Decimal phases appear between their surrounding integers in numeric order.
|
||||
- [ ] **Phase 12: Tender Notifications** - Configurable digest and instant email alerts without duplicate sends or backfill floods
|
||||
- [ ] **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 15: Modul-Berechtigungen: Gruppen & User-Grants** - Modulzugriff pro Gruppe und pro Benutzer zusätzlich zur Mandanten-Aktivierung, Gruppen mit optionaler AD-Bindung
|
||||
|
||||
## Phase Details
|
||||
|
||||
@@ -485,10 +487,41 @@ Plans:
|
||||
|
||||
**UI hint**: yes
|
||||
|
||||
### Phase 15: Modul-Berechtigungen: Gruppen & User-Grants
|
||||
|
||||
**Goal:** Modulzugriff wird zweistufig: die bestehende Mandanten-Aktivierung bleibt Voraussetzung, darüber hinaus entscheiden Freigaben pro Gruppe und pro einzelnem Benutzer, wer ein Modul sieht und dessen API nutzen darf. Admins verwalten Gruppen (optional an eine AD-Gruppe gebunden) und eine Freigabe-Matrix pro Modul im Admin-UI.
|
||||
**Depends on**: Phase 14
|
||||
**Requirements**: TBD (werden in /gsd-plan-phase 15 vergeben)
|
||||
**Success Criteria** (what must be TRUE):
|
||||
|
||||
1. Ein Admin kann im Admin-UI Gruppen anlegen, umbenennen und löschen sowie Benutzer manuell zuweisen und entfernen
|
||||
2. Eine Gruppe kann optional an einen AD-Gruppen-DN gebunden werden; der LDAP-Sync trägt die Mitglieder aus `memberOf` ein und entfernt dabei keine manuell gesetzten Mitglieder
|
||||
3. Ein Admin kann ein mandantenweit aktives Modul gezielt für Gruppen und/oder einzelne Benutzer freigeben und die Freigabe wieder entziehen
|
||||
4. Ohne Freigabe hat ein USER keinen Zugriff: das Modul fehlt in der Sidebar, die Modulseite ist gesperrt und die Modul-API antwortet mit 403 — Sidebar und API nutzen dieselbe Zugriffsauflösung
|
||||
5. ADMIN und SUPER_ADMIN sehen und nutzen innerhalb ihres Mandanten alle aktiven Module ohne Freigabe
|
||||
6. Nach der Migration hat kein bestehender Benutzer Zugriff verloren: pro Mandant existiert eine Gruppe „Alle Benutzer" mit allen Bestandsbenutzern und Freigaben für alle zum Migrationszeitpunkt aktiven Module
|
||||
|
||||
**Design-Entscheidungen** (mit User geklärt am 2026-08-04):
|
||||
|
||||
- Gruppenquelle: Tessera-eigene Gruppen mit optionaler AD-Bindung (`Group.ldapDn`), nicht reine AD-Spiegelung
|
||||
- Default: geschlossen — ohne Grant kein Zugriff (Migration verhindert Lockout)
|
||||
- Bypass: ADMIN + SUPER_ADMIN umgehen Grants innerhalb ihres Mandanten
|
||||
- Tiefe: nur Modulzugriff an/aus, keine Rechtestufen (read/write) innerhalb der Module
|
||||
|
||||
**Neue Modelle**: `Group` (tenantId, name, ldapDn?), `GroupMembership` (userId, groupId, source MANUAL|LDAP), `ModuleGrant` (tenantId, moduleId, groupId? | userId?)
|
||||
|
||||
**Plans**: 0 plans
|
||||
|
||||
Plans:
|
||||
|
||||
- [ ] TBD (run /gsd-plan-phase 15 to break down)
|
||||
|
||||
**UI hint**: yes
|
||||
|
||||
## Progress
|
||||
|
||||
**Execution Order:**
|
||||
Phases execute in numeric order: 1 -> 2 -> 3 -> 4 -> 5 -> 6 -> 7 -> 8 -> 9 -> 10 -> 11 -> 12 -> 13 -> 14
|
||||
Phases execute in numeric order: 1 -> 2 -> 3 -> 4 -> 5 -> 6 -> 7 -> 8 -> 9 -> 10 -> 11 -> 12 -> 13 -> 14 -> 15
|
||||
|
||||
| Phase | Plans Complete | Status | Completed |
|
||||
|-------|----------------|--------|-----------|
|
||||
@@ -506,3 +539,4 @@ Phases execute in numeric order: 1 -> 2 -> 3 -> 4 -> 5 -> 6 -> 7 -> 8 -> 9 -> 10
|
||||
| 12. Tender Notifications | 4/4 | In Progress| |
|
||||
| 13. Scraping Adapters & Cross-Source Deduplication | 6/6 | In Progress| |
|
||||
| 14. RSS, Email-Alert Ingestion & Module Rollout | 5/5 | In Progress| |
|
||||
| 15. Modul-Berechtigungen: Gruppen & User-Grants | 0/0 | Not Planned | |
|
||||
|
||||
@@ -103,6 +103,10 @@ Progress: [██████████] 99%
|
||||
|
||||
## Accumulated Context
|
||||
|
||||
### Roadmap Evolution
|
||||
|
||||
- Phase 15 added (2026-08-04): Modul-Berechtigungen — Gruppen & User-Grants. Zweistufiger Modulzugriff (Mandanten-Aktivierung + Grants pro Gruppe/User), Gruppen mit optionaler AD-Bindung, default geschlossen, ADMIN/SUPER_ADMIN umgehen Grants, nur Zugriff an/aus. Startet Milestone v1.2 Plattform-Berechtigungen.
|
||||
|
||||
### Decisions
|
||||
|
||||
Decisions are logged in PROJECT.md Key Decisions table.
|
||||
|
||||
Reference in New Issue
Block a user