573 lines
28 KiB
Markdown
573 lines
28 KiB
Markdown
---
|
|
kind: wireframe-package
|
|
project: HiveGrid Screen Project
|
|
ticket: D-P2
|
|
package: WF-P2 Admin RBAC
|
|
typ: Admin Flow
|
|
status: In Subframe
|
|
subframe: "https://app.subframe.com/f023064a5ca0/flow/42c54a17-9c08-4db3-9306-1449f5b874e4/edit"
|
|
canvas: WF-P2 Admin RBAC.canvas
|
|
---
|
|
|
|
# WF-P2 Admin RBAC
|
|
|
|
Status: In Subframe
|
|
Subframe-Link: https://app.subframe.com/f023064a5ca0/flow/42c54a17-9c08-4db3-9306-1449f5b874e4/edit
|
|
Canvas: [[WF-P2 Admin RBAC.canvas]]
|
|
Stand: 2026-06-23
|
|
|
|
---
|
|
|
|
## 1. Kurzfassung
|
|
|
|
Dieses Paket plant die Admin-Flaechen aus D-P2 fuer Rollen, Berechtigungen und Mitarbeiter. Gruppen sind nach Produktentscheidung nicht Teil dieses Pakets.
|
|
|
|
Der wichtigste UX-Risikopunkt ist das sichere Bearbeiten von Rollen/Permissions. Reassign beim Deaktivieren wird fuer v1 bewusst in den Backlog gelegt.
|
|
|
|
---
|
|
|
|
## 2. Intent Check
|
|
|
|
| Frage | Antwort |
|
|
|---|---|
|
|
| Welches Ticket/Modul ist betroffen? | D-P2 Auth / RBAC / Tenant Users |
|
|
| Was soll der Nutzer am Ende schaffen? | Mitarbeiter einladen/verwalten, Rollen zuweisen und Rollen/Permissions pflegen |
|
|
| Ist es ein Flow, einzelner Screen, Zustand oder nur Dokumentation? | Admin-Paket mit Listen, Editoren und Modal-/Workflow-Zustaenden |
|
|
| Welche Planning-Quellen wurden geprueft? | D-P2, SCREEN-MAP §1 Auth-Screens, bestehende Settings-Routen `roles-and-permissions` |
|
|
| Was ist sicher im Scope? | Mitarbeiter/Rollen-Zuweisung, Rollen-Subpage mit Rechtebereichen, Einladungsmodal, einfache Deaktivieren-Bestaetigung |
|
|
| Was ist sicher nicht im Scope? | Gruppen, Plattform-Admin, Feature-Flags, Audit-Viewer |
|
|
| Gibt es Admin/Normalrolle-Unterschiede? | Ja, nur Admins duerfen diese Flaechen sehen/bearbeiten |
|
|
| Welche Annahmen sind noch unsicher? | keine fuer v1; konkrete Permission-Zuschnitte werden im Development finalisiert |
|
|
|
|
---
|
|
|
|
## 3. Scope
|
|
|
|
| Punkt | Inhalt |
|
|
|---|---|
|
|
| Ticket/Modul | D-P2 Auth |
|
|
| Nutzerrolle | Tenant-Admin |
|
|
| Admin-Variante | Vollzugriff auf Rollen, Permissions-Katalog und Mitarbeiter |
|
|
| Normale Rolle | Keine Berechtigung / kein Zugriff |
|
|
| Startpunkt | Settings -> Mitarbeiter |
|
|
| Ziel | Tenant-Team und Rechte verwalten |
|
|
| Haupt-Archetyp | A2 List + A5 Modal + A6 Settings |
|
|
| Bespoke-Anteil | nein |
|
|
| Out of scope | Gruppen, Audit, Plattform-Admin, Billing |
|
|
|
|
---
|
|
|
|
## 4. Brainstorming
|
|
|
|
### Flow-Frage
|
|
|
|
Wie schneiden wir RBAC so, dass es genug fuer Dev/Handoff ist, aber nicht zu einem riesigen Admin-Board wird?
|
|
|
|
### UX-Varianten
|
|
|
|
| Option | Beschreibung | Vorteil | Nachteil | Empfehlung |
|
|
|---|---|---|---|---|
|
|
| A | Settings-Bereich mit Tabs: Mitarbeiter, Rollen und Berechtigungen | kompakt, gut scanbar | mehrere Arbeitsmomente | genommen |
|
|
| B | Ein grosses Team-Admin-Dashboard | alles zentral | zu breit und schwer zu validieren | raus |
|
|
| C | Nur Mitarbeiter bauen, Rollen spaeter | schneller | D-P2-Luecke bleibt offen | raus |
|
|
| D | Gruppen als Teil des RBAC-Pakets | bildet D-P2 voll ab | fuer v1 zu viel und fachlich nicht benoetigt | raus |
|
|
|
|
### Entscheidung
|
|
|
|
| Entscheidung | Status | Notiz |
|
|
|---|---|---|
|
|
| Settings-Struktur statt separatem Admin-Center | genommen | bestehende Route ist `Settings -> Roles & Permissions` |
|
|
| Gruppen raus | genommen | Gruppen werden in diesem Paket nicht gebaut |
|
|
| Startrollen | genommen | Zum Start gibt es nur die Systemrolle `Admin`; weitere Rollen legt der Admin selbst an |
|
|
| Rollen-Vorlagen | WIP | Beim Erstellen koennen spaeter Vorlagen angeboten werden, sind aber noch nicht final |
|
|
| Eigene Rollen anlegen und benennen | genommen | Rollen-Editor erlaubt Custom Roles |
|
|
| Rollen-Editor als eigener Arbeitsmoment | genommen | Permission-Bundles + Advanced brauchen Raum |
|
|
| Kein separater Berechtigungen-Tab | genommen | Berechtigungen sind fuer Admins Teil des Tabs `Rollen und Berechtigungen` |
|
|
| Einladung als Modal | genommen | A5, kein eigener Fullscreen noetig |
|
|
| Deaktivieren mit Reassign | Backlog | v1 macht nur einfache Deaktivieren-Bestaetigung |
|
|
| Keine-Berechtigung-Zustand dokumentieren | genommen | normale Nutzer duerfen Admin-Flaechen nicht sehen |
|
|
|
|
### Happy Path
|
|
|
|
1. Admin oeffnet Mitarbeiterliste.
|
|
2. Admin laedt Nutzer ein und weist eine oder mehrere Rollen zu.
|
|
3. Admin nutzt `Admin` als geschuetzte Systemrolle oder erstellt eine eigene Rolle mit eigenem Namen.
|
|
4. Wenn ein Nutzer deaktiviert wird, bestaetigt der Admin eine kurze Sicherheitsfrage.
|
|
|
|
### Varianten / Branches
|
|
|
|
- Rolle anlegen: Name, Beschreibung und Permission-Bundles auswaehlen.
|
|
- Rolle bearbeiten: Permission-Bundles anpassen.
|
|
- Rolle loeschen: nur moeglich, wenn keine Mitarbeiter zugewiesen sind; sonst kleines Blocker-Modal und manuelle Umzuweisung.
|
|
- Nutzer deaktivieren: kurzes Confirm-Modal; Status wird danach `Deaktiviert`.
|
|
- Einladung laeuft ab oder wird erneut gesendet.
|
|
- Admin versucht letzten Admin zu deaktivieren.
|
|
|
|
### Roadblocks
|
|
|
|
- keine Berechtigung
|
|
- letzter Admin
|
|
- Rolle in Benutzung
|
|
- Rollenname existiert bereits
|
|
- Einladung bereits vorhanden
|
|
- Reassign-Ziel fehlt nur spaeter relevant, Backlog
|
|
|
|
### Meldungs-/Error-State-Brainstorming
|
|
|
|
| Ereignis | UI-Form | Blockiert? | Bauen? | Copy/Notiz |
|
|
|---|---|---|---|---|
|
|
| Einladung gesendet | Toast | nein | nein | Erfolg |
|
|
| Einladung existiert | Inline/Modal-Hinweis | ja | nein | erneutes Senden anbieten |
|
|
| Rolle in Benutzung | kleines Blocker-Modal | ja | Nur dokumentieren | Loeschen erst nach manueller Umzuweisung moeglich |
|
|
| Rollenname existiert | Inline | ja | nein | Name muss eindeutig sein |
|
|
| Nutzer deaktivieren | kleines Modal | ja | ja | einfache Bestaetigung |
|
|
| Letzter Admin | Blocker | ja | pruefen | sicherheitskritisch |
|
|
| Keine Berechtigung | A7 State | ja | nein | wiederverwenden |
|
|
|
|
---
|
|
|
|
## 5. Screen-Kandidaten nach Entscheidung
|
|
|
|
| Kandidat | Warum eventuell noetig? | Erste Einschaetzung |
|
|
|---|---|---|
|
|
| Mitarbeiter & Rollen | zentrale Zuweisung von Rollen an User | Bauen |
|
|
| Einladung Modal | neuer Nutzer | Bauen/Wiederverwenden A5 |
|
|
| Rollen-Dropdown in Mitarbeiterliste | direkte Rollenzuweisung und Sprung zum Tab `Rollen und Berechtigungen` | Nur dokumentieren |
|
|
| Mitarbeiter deaktivieren | einfache Sicherheitsbestaetigung | Bauen |
|
|
| Deaktivieren mit Reassign | spaetere Uebertragung offener Verantwortlichkeiten | Backlog |
|
|
| Rollen und Berechtigungen | Systemrolle `Admin` und eigene Rollen verwalten | Bauen |
|
|
| Rolle anlegen/bearbeiten | eigene Rollen anlegen/benennen und atomar Permissions setzen | In S02 loesen |
|
|
| Rechtebereiche im Tab `Rollen und Berechtigungen` | erklaert Berechtigungen im Kontext der Rolle | In S02 loesen |
|
|
| Rolle loeschen mit Ersatzrolle | verhindert Rechteverlust | Backlog |
|
|
| Letzter Admin blockiert | Sicherheitsblocker | Validiert |
|
|
|
|
---
|
|
|
|
## 6. Rollen- und Permission-Vorschlag
|
|
|
|
### Rollenmodell
|
|
|
|
| Typ | Rolle | Zweck | Notiz |
|
|
|---|---|---|---|
|
|
| Systemrolle | Admin | Vollzugriff auf Mitarbeiter, Rollen, Workspace-Settings und kritische Admin-Funktionen | einzige sichtbare Systemrolle |
|
|
| Custom Role | frei benennbar | Admin legt eigene Rolle an | Name, Beschreibung, Bereich und Permission-Bereiche |
|
|
|
|
Notiz: Es gibt in v1 keine sichtbaren vordefinierten Rollen ausser `Admin`. Vorlagen wie Geschaeftsfuehrer, Projektleiter, Verwaltung, Vertriebler, Kundensupporter oder Monteur koennen spaeter beim Erstellen einer Rolle angeboten werden, sind aber Work in Progress und nicht Teil der initialen Rollenliste.
|
|
|
|
### Permission-Bundles fuer den Editor
|
|
|
|
Die folgenden Bundles sind nur ein Arbeitsgeruest fuer Planung und Wireframe. Sie muessen nicht vollstaendig vorgebaut werden; Development kann den finalen Rechtekatalog spaeter sauber ausmodellieren. Fuer das UI reicht in v1 ein konkretes Permission-Zeilenmuster im Rollen-Modal.
|
|
|
|
| Bundle | Enthalt grob | Relevanz fuer v1 |
|
|
|---|---|---|
|
|
| Basiszugriff | Dashboard/App betreten, eigene Daten sehen | direkt |
|
|
| Mitarbeiter | Mitglieder sehen, einladen, bearbeiten, deaktivieren | direkt |
|
|
| Rollen & Berechtigungen | Rollen ansehen, Rollen setzen, Custom Roles pflegen | direkt |
|
|
| Workspace Settings | Workspace/Account Settings sehen und bearbeiten | direkt |
|
|
| Abrechnung | Subscription, Rechnungen, Rechnungsdaten | direkt/teilweise |
|
|
| Audit & Sicherheit | Audit-Log sehen, sicherheitsrelevante Admin-Einsicht | direkt/teilweise |
|
|
| Integrationen/API | API Keys, Plugins, technische Anbindungen | direkt/teilweise |
|
|
| CRM/Kunden | Kunden/Firmen/Kontakte lesen/schreiben/admin | fachliches Modul, ggf. spaeter |
|
|
| Leads/Vertrieb | Leads, Angebote, Pipeline, Umsatzfelder | fachliches Modul, ggf. spaeter |
|
|
| Projekte/Auftraege | Projekte, Auftraege, Planung, Zuweisungen | fachliches Modul, ggf. spaeter |
|
|
| Aufgaben/Dateien | Tasks, Dokumente, Uploads, Freigaben | fachliches Modul, ggf. spaeter |
|
|
| Kommunikation/Support | Anfragen, Chat, Telefonie/Support-Kontext | fachliches Modul, ggf. spaeter |
|
|
|
|
### Rollen-Vorlagen WIP
|
|
|
|
| Vorlage | Permission-Richtung | Status |
|
|
|---|---|---|
|
|
| Geschaeftsfuehrer | fast alles, inklusive Mitarbeiter, Rollen, Workspace Settings, Abrechnung, Audit | WIP, nicht in v1-Rollenliste |
|
|
| Projektleiter | Projekte/Auftraege, Aufgaben/Dateien, Team-Ueberblick, Mitglieder nur lesen | WIP |
|
|
| Verwaltung | Mitarbeiter lesen, Workspace/Account-Basis, Abrechnung/Rechnungen, Kunden-/Projekt-Ueberblick | WIP |
|
|
| Vertriebler | CRM/Kunden, Leads/Vertrieb, Angebote, eigene Pipeline | WIP |
|
|
| Kundensupporter | Kundenkommunikation, Supportfaelle, lesender Projekt-/Kundenkontext | WIP |
|
|
| Monteur | eigene/zugewiesene Auftraege, Aufgaben, Dateien, mobile Ausfuehrung | WIP |
|
|
|
|
---
|
|
|
|
## 7. Grober Screen-Aufbau
|
|
|
|
### Settings-Aufteilung
|
|
|
|
Entscheidung: Option A ist genommen. Das Paket lebt unter `Settings -> Mitarbeiter`. Darin liegen nur die Tabs `Mitarbeiter` und `Rollen und Berechtigungen`.
|
|
|
|
| Option | Aufbau | Vorteil | Nachteil |
|
|
|---|---|---|---|
|
|
| A | `Settings -> Mitarbeiter` als Oberpunkt mit Tabs `Mitarbeiter`, `Rollen und Berechtigungen` | fuer Admins intuitiv und kompakt | technische Berechtigungen sind nur im Rollen-Kontext sichtbar |
|
|
| B | `Settings -> Rollen & Berechtigungen` als Oberpunkt mit Tabs `Mitarbeiter`, `Rollen`, `Berechtigungen` | passt zur bestehenden Code-Struktur | zu technisch und weniger kompakt |
|
|
| C | zwei Settings-Punkte: `Mitarbeiter` und `Rollen & Berechtigungen` | klare Trennung zwischen Menschen und Rechte-System | mehr Navigation, Rollen-Zuweisung springt zwischen Bereichen |
|
|
|
|
Die technische Route kann spaeter weiterhin an die bestehende App-Struktur angepasst werden; fuer Wireframes und Navigation ist der sichtbare Einstieg `Settings -> Mitarbeiter`.
|
|
|
|
### Validierungsreihenfolge
|
|
|
|
Wir validieren einzeln und legen erst danach Screen-Dateien/Canvas an.
|
|
|
|
1. `S01 Mitarbeiterliste`
|
|
2. `M01 Mitarbeiter einladen`
|
|
3. Rollen-Dropdown innerhalb `S01 Mitarbeiterliste` pruefen; D01 bleibt nur Dokumentation, kein eigener Subframe-Screen
|
|
4. `M03 Mitarbeiter deaktivieren`
|
|
5. `S02 Rollen und Berechtigungen`
|
|
6. `M04A Rolle anlegen`
|
|
7. `M04B Rolle duplizieren`
|
|
8. `M02 Rolle bearbeiten`
|
|
9. `D03 Rolle in Nutzung blockiert`
|
|
|
|
### S01 Mitarbeiterliste
|
|
|
|
Ziel: Admin findet schnell Nutzer und kann Rollen/Status pruefen.
|
|
|
|
Layout:
|
|
|
|
1. Header: `Mitarbeiter`, kurze Beschreibung, Primaer-CTA `Mitarbeiter einladen`.
|
|
2. Tab-Leiste innerhalb `Settings -> Mitarbeiter`: `Mitarbeiter`, `Rollen und Berechtigungen`.
|
|
3. Toolbar:
|
|
- Suchfeld: Name, E-Mail, Telefonnummer.
|
|
- Filter `Rolle` als Multi-Select.
|
|
- Filter `Abteilung` als Multi-Select.
|
|
- Filter `Status`: Aktiv, Eingeladen, Deaktiviert.
|
|
- Filter `2FA`: Aktiv, Nicht eingerichtet.
|
|
- Aktive Filter als Chips mit `Alle zuruecksetzen`.
|
|
4. Tabelle:
|
|
- Mitarbeiter: Avatar, Name, E-Mail.
|
|
- Abteilung.
|
|
- Rollen als Dropdown/Select.
|
|
- Status.
|
|
- 2FA.
|
|
- Aktionen: 3-Punkte-Menue rechts.
|
|
5. Empty/Filtered State:
|
|
- keine Treffer fuer Suche/Filter.
|
|
- Link/Button zum Filter zuruecksetzen.
|
|
6. Rollen-Dropdown:
|
|
- zeigt aktuelle Rolle(n).
|
|
- erlaubt direkte Rollenauswahl, sofern Admin die Berechtigung hat.
|
|
- enthaelt Eintrag `Rollen und Berechtigungen bearbeiten`.
|
|
- `Rollen und Berechtigungen bearbeiten` navigiert in den Tab `Rollen und Berechtigungen` unter `Settings -> Mitarbeiter`.
|
|
7. Zeilenaktionen:
|
|
- rechts in jeder Tabellenzeile ein 3-Punkte-Menue.
|
|
- enthaelt kontextabhaengig `Einladung erneut senden`, `Deaktivieren`, ggf. `Profil oeffnen`.
|
|
|
|
### M03 Mitarbeiter deaktivieren
|
|
|
|
Ziel: Admin bestaetigt eine einfache Deaktivierung eines Mitarbeiters.
|
|
|
|
Layout:
|
|
|
|
1. Kleines Confirm-Modal aus der Mitarbeiterliste.
|
|
2. Headline: `Mitarbeiter deaktivieren?`
|
|
3. Inhalt:
|
|
- Name und E-Mail des Mitarbeiters.
|
|
- kurzer Hinweis, dass der Mitarbeiter danach keinen Zugriff mehr auf den Workspace hat.
|
|
- Hinweis, dass der Mitarbeiter in der Liste mit Status `Deaktiviert` sichtbar bleibt.
|
|
4. Aktionen:
|
|
- Primaer/Danger: `Deaktivieren`
|
|
- Sekundaer: `Abbrechen`
|
|
5. Nach Erfolg:
|
|
- Modal schliesst.
|
|
- Toast `Mitarbeiter wurde deaktiviert`.
|
|
- Tabellenstatus wechselt auf `Deaktiviert`.
|
|
6. Nicht in v1:
|
|
- Reassign offener Verantwortlichkeiten.
|
|
- mehrstufiger Workflow.
|
|
|
|
### S02 Rollen und Berechtigungen
|
|
|
|
Ziel: Admin verwaltet Rollen als eigene Subpage innerhalb `Settings -> Mitarbeiter`, nicht als Modal aus der Mitarbeiterliste. Berechtigungen werden nur hier im Kontext der Rolle sichtbar.
|
|
|
|
Layout:
|
|
|
|
1. Header: `Rollen und Berechtigungen`, CTA `Rolle anlegen`.
|
|
2. Toolbar:
|
|
- Suchfeld: Rollenname, Beschreibung.
|
|
- Filter `Typ`: Systemrolle, Eigene Rolle.
|
|
- Filter `Permission-Bereich`: z. B. Mitarbeiter, Abrechnung, Dateien, Aufgaben.
|
|
- Filter `In Nutzung`: mit Mitgliedern / ohne Mitglieder.
|
|
3. Tabelle:
|
|
- Rolle.
|
|
- Beschreibung.
|
|
- Typ: Systemrolle, Eigene Rolle.
|
|
- Mitglieder: Avatar-Stack oder Anzahl.
|
|
- Status: Aktiv, Pruefen.
|
|
- Aktionen: 3-Punkte-Menue rechts.
|
|
4. Zeilenaktionen:
|
|
- rechts in jeder Tabellenzeile ein 3-Punkte-Menue.
|
|
- enthaelt `Bearbeiten`, `Duplizieren`, `Loeschen`.
|
|
- bei Systemrolle `Admin` keine Loeschen-Aktion.
|
|
5. Rollen-Bearbeitung:
|
|
- passiert in diesem Tab/Subpage-Kontext.
|
|
- `Rolle anlegen` oeffnet M04A mit Basisdaten.
|
|
- `Bearbeiten` oeffnet M02 direkt im grossen Permission-Editor.
|
|
- `Duplizieren` oeffnet M04B mit vorausgefuellten Basisdaten.
|
|
- das Modal ist nicht aus der Mitarbeiterliste heraus erreichbar, sondern nur aus `Rollen und Berechtigungen`.
|
|
6. Rechtebereiche:
|
|
- werden beim Bearbeiten einer Rolle angezeigt.
|
|
- keine separate Hauptnavigation.
|
|
- optional mit Advanced-Einzelrechten als ausklappbare Details.
|
|
7. Loeschzustand:
|
|
- wenn keine Mitglieder zugewiesen sind, kann eine Rolle geloescht werden.
|
|
- wenn die Rolle noch genutzt wird, erscheint ein kleines Blocker-Modal.
|
|
- Copy-Richtung: `Diese Rolle kann nicht geloescht werden, solange Mitarbeiter zugewiesen sind.`
|
|
- Aktion: `Verstanden`; Admin weist Mitglieder danach manuell einer anderen Rolle zu.
|
|
- Ersatzrolle/Bulk-Reassign bleibt Backlog.
|
|
|
|
### M04A Rolle anlegen
|
|
|
|
Ziel: Admin klaert bei einer komplett neuen eigenen Rolle zuerst Name, Beschreibung und Bereich, bevor die atomaren Berechtigungen gesetzt werden.
|
|
|
|
Einstieg:
|
|
|
|
1. `Rolle anlegen` aus S02 oeffnet M04A mit leerem Formular.
|
|
2. `Bearbeiten` nutzt M04A nicht und springt direkt in M02.
|
|
3. `Duplizieren` nutzt M04A nicht, sondern M04B.
|
|
|
|
Layout:
|
|
|
|
1. Modal-Step ueber `S02 Rollen und Berechtigungen`, mit Schliessen-Icon.
|
|
2. Headline: `Rolle anlegen`.
|
|
3. Formular:
|
|
- Rollenname als Pflichtfeld.
|
|
- Beschreibung als optionales Textfeld.
|
|
- Bereich/Kategorie als Select, z. B. Team, Verwaltung, Operativ.
|
|
4. Optionaler Bereich `Vorlage verwenden`:
|
|
- nur als Work-in-Progress-Platzhalter.
|
|
- Vorlagen sind keine Seed-Rollen und erscheinen nicht in der Rollenliste.
|
|
5. Footer:
|
|
- `Weiter zu Berechtigungen` fuehrt zu M02.
|
|
- `Abbrechen` schliesst den Modal-Step.
|
|
|
|
Subframe:
|
|
|
|
- M04A ist der bestehende Subframe-Screen fuer `Rolle anlegen`.
|
|
- Der Screen bleibt als Dialog/Modal-Step ueber S02 gedacht.
|
|
|
|
### M04B Rolle duplizieren
|
|
|
|
Ziel: Admin nutzt eine bestehende eigene Rolle als Startpunkt, passt die Basisdaten an und landet danach im grossen Permission-Editor mit kopierten Berechtigungen.
|
|
|
|
Einstieg:
|
|
|
|
1. `Duplizieren` aus dem Zeilenmenue in S02 oeffnet M04B mit vorausgefuellten Basisdaten.
|
|
2. `Rolle anlegen` nutzt M04B nicht, sondern M04A.
|
|
3. `Bearbeiten` nutzt M04B nicht und springt direkt in M02.
|
|
|
|
Layout:
|
|
|
|
1. Modal-Step ueber `S02 Rollen und Berechtigungen`, mit Schliessen-Icon.
|
|
2. Headline: `Rolle duplizieren`.
|
|
3. Hinweisblock: Basisdaten und Berechtigungen werden aus der Quellrolle kopiert.
|
|
4. Formular:
|
|
- Rollenname als Pflichtfeld, vorausgefuellt z. B. als `Kopie von ...`.
|
|
- Beschreibung als optionales Textfeld.
|
|
- Bereich/Kategorie als Select.
|
|
5. Footer:
|
|
- `Weiter zu Berechtigungen` fuehrt zu M02.
|
|
- `Abbrechen` schliesst den Modal-Step.
|
|
|
|
Subframe:
|
|
|
|
- M04B ist der bestehende Subframe-Screen fuer `Rolle duplizieren`.
|
|
- Der Screen bleibt als Dialog/Modal-Step ueber S02 gedacht.
|
|
|
|
### M02 Rolle bearbeiten
|
|
|
|
Ziel: Admin bearbeitet die Basisdaten und Berechtigungen einer vorhandenen oder gerade angelegten eigenen Rolle, ohne die Rollen-Subpage zu verlassen. Die Systemrolle `Admin` ist geschuetzt.
|
|
|
|
Einstiege:
|
|
|
|
1. `Bearbeiten` auf einer bestehenden Rolle oeffnet direkt den grossen Permission-Editor.
|
|
- Der Admin landet sofort im Editor, oben im Bereich `Rolle`.
|
|
- Rollenname, Beschreibung und Bereich/Kategorie bleiben dort weiterhin editierbar.
|
|
2. `Rolle anlegen` kommt aus M04A und uebergibt die Basisdaten in den Editor.
|
|
3. `Duplizieren` kommt aus M04B, mit vorausgefuellten Basisdaten und kopierten Berechtigungen.
|
|
|
|
Layout:
|
|
|
|
1. Sehr grosser Modal-Flow ueber dem Tab `Rollen und Berechtigungen`.
|
|
2. Modal kann jederzeit geschlossen werden.
|
|
3. Im Editor steht oben der Bereich `Rolle`:
|
|
- Rollenname.
|
|
- Beschreibung.
|
|
- Bereich/Kategorie der Rolle, z. B. Team, Verwaltung, Operativ.
|
|
- Typ als Information: `Systemrolle` oder `Eigene Rolle`; nicht frei umstellbar.
|
|
- diese Daten koennen auch nach M04A/M04B weiterhin bearbeitet werden.
|
|
4. Linke Sidebar:
|
|
- oben links sitzt die globale Suche, aehnlich Apple-Einstellungen.
|
|
- darunter stehen die Bereiche als Navigation.
|
|
- Beispiele: Rolle, Allgemein, Mitarbeiter, Rollen und Berechtigungen, Workspace Settings, Abrechnung, Audit & Sicherheit, Integrationen/API, Dateien, Aufgaben.
|
|
- Klick springt zum jeweiligen Bereich im scrollbaren Modal.
|
|
5. Globale Berechtigungs-Suche:
|
|
- Suchfeld links ueber der Sidebar.
|
|
- durchsucht alle Berechtigungen/Rechtebereiche ueber alle Module hinweg.
|
|
- filtert die sichtbaren Treffer bereichsuebergreifend.
|
|
- Treffer bleiben ihren Bereichsueberschriften zugeordnet, damit Kontext erhalten bleibt.
|
|
6. Hauptbereich:
|
|
- startet oben mit `Rolle`.
|
|
- darunter folgen `Allgemein` und die weiteren Rechtebereiche.
|
|
- die Bereichsueberschriften entsprechen den Eintraegen in der linken Sidebar.
|
|
- Admin kann durch alle Bereiche nach unten scrollen.
|
|
7. Permission-Abschnitte:
|
|
- jeder Bereich hat einzelne Zeilen mit Toggle-Switches, um Berechtigungen an- oder auszuschalten.
|
|
- Bereich kann eine Kurzbeschreibung enthalten.
|
|
- einzelne technische Rechte koennen als Advanced Details aufgeklappt werden, falls noetig.
|
|
8. Permission-Zeilenmuster:
|
|
- eine Beispiel-Permission wird im Wireframe konkret vorgebaut.
|
|
- Aufbau als Tabelle/Liste wie in der Referenz: links Setting/Permission, mittig Beschreibung, rechts Enable/Disable.
|
|
- Beispiel-Ueberschrift: `Mitarbeiter ansehen`.
|
|
- Beispiel-Beschreibung: `Darf Mitarbeiterliste und Mitarbeiterprofile im Workspace lesen.`
|
|
- Control: Toggle-Switch `An/Aus`.
|
|
- Wenn ein Recht Abstufungen braucht, kann spaeter `Read-only/Bearbeiten` als Detail/Advanced Control ergaenzt werden.
|
|
- weitere Permissions koennen Development-seitig nach diesem Muster ergaenzt werden.
|
|
9. Footer:
|
|
- Speichern.
|
|
- Abbrechen.
|
|
- ggf. Rolle loeschen als Danger Action.
|
|
|
|
## 8. Screen Validation Gate
|
|
|
|
| ID | Screen/Zustand | Ist eigener Arbeitsmoment? | Neue Struktur/Entscheidung/Risiko? | Entscheidung | Begruendung |
|
|
|---|---|---|---|---|---|
|
|
| S01 | Mitarbeiterliste | ja | ja | Validiert | Suche, Filter, Tabelle und Aktionen passen erstmal |
|
|
| M01 | Mitarbeiter einladen | ja | ja | Validiert | Modal mit E-Mail, optional Name/Abteilung und Rollen |
|
|
| D01 | Rollen-Dropdown in Mitarbeiterliste | nein | ja | Validiert | direkte Rollenauswahl; Bearbeiten fuehrt in `Rollen und Berechtigungen` |
|
|
| M03 | Mitarbeiter deaktivieren | ja | ja | Validiert | kleines Confirm-Modal, kein Reassign |
|
|
| S02 | Rollen und Berechtigungen | ja | ja | Validiert | Rollen-Tabelle nach Referenz, 3-Punkte-Menue, nur Systemrolle Admin |
|
|
| M04A | Rolle anlegen | ja | ja | Validiert | eigener Basisdaten-Step fuer neue Rollen vor dem Permission-Editor |
|
|
| M04B | Rolle duplizieren | ja | ja | Validiert | eigener Basisdaten-Step fuer duplizierte Rollen mit Quellrollen-Kontext |
|
|
| M02 | Rolle bearbeiten | ja | ja, Permissions | Validiert | grosses Modal mit Sidebar, Ueberblick, globaler Suche und Rechte-Toggles |
|
|
| D03 | Rolle in Nutzung blockiert | nein | ja | Validiert | Loeschen nur ohne Mitglieder; sonst kleines Blocker-Modal, Ersatzrolle/Bulk-Reassign im Backlog |
|
|
| V01 | Letzter Admin blockiert | ja | ja, Sicherheitsblocker | Validiert | kleiner Blocker-State im jeweiligen Kontext |
|
|
|
|
### Copy-kritische Zustaende
|
|
|
|
| Zustand | Bauen? | Warum / Copy-Entscheidung |
|
|
|---|---|---|
|
|
| Mitarbeiter deaktivieren | ja | kurzer Sicherheitsmoment |
|
|
| Letzter Admin blockiert | ja | kleiner Blocker-State im jeweiligen Kontext |
|
|
| Rolle in Benutzung | Nur dokumentieren | kleines Blocker-Modal; Ersatzrolle/Bulk-Reassign liegt im Backlog |
|
|
| Custom Role anlegen | ja | muss klar zwischen Vorlage und eigener Rolle unterscheiden |
|
|
|
|
### Blockierende Error States
|
|
|
|
| Zustand | UI-Form | Primaeraktion | Sekundare Aktion | Inhalt/Copy-Richtung |
|
|
|---|---|---|---|---|
|
|
| Letzter Admin | Screen/Modal | weiteren Admin bestimmen | abbrechen | kein Tenant ohne Admin |
|
|
| Reassign-Ziel fehlt | Backlog | - | - | spaeter fuer Reassign-Workflow |
|
|
| Rolle in Benutzung | kleines Blocker-Modal | Verstanden | - | Rolle kann erst geloescht werden, wenn keine Mitarbeiter mehr zugewiesen sind |
|
|
| Rollenname existiert | Inline | Namen aendern | abbrechen | eindeutige Rollennamen |
|
|
|
|
---
|
|
|
|
## 9. Validierte Screen-Liste
|
|
|
|
Alle aktiven Screen-Kandidaten sind von David validiert. Das Rollenmodell startet nur mit `Admin` plus eigenen Rollen; Vorlagen und finaler Rechtekatalog werden spaeter ausgearbeitet.
|
|
|
|
| ID | Screen/Zustand | Typ | Umsetzung | Ort | Status |
|
|
|---|---|---|---|---|---|
|
|
| S01 | Mitarbeiterliste | Admin List | Bauen | `Settings -> Mitarbeiter`, Tab `Mitarbeiter` | Validiert |
|
|
| M01 | Mitarbeiter einladen | Modal | Bauen | von S01 | Validiert |
|
|
| D01 | Rollen-Dropdown in Mitarbeiterliste | Inline-Zustand in S01 | Nur dokumentieren | in S01, kein eigener Subframe-Screen | Validiert |
|
|
| M03 | Mitarbeiter deaktivieren | Confirm Modal | Bauen | von S01 | Validiert |
|
|
| S02 | Rollen und Berechtigungen | Settings Subpage | Bauen | `Settings -> Mitarbeiter`, Tab `Rollen und Berechtigungen` | Validiert |
|
|
| M04A | Rolle anlegen | Modal Step | Bauen | von S02 CTA Rolle anlegen | Subframe: Rolle anlegen |
|
|
| M04B | Rolle duplizieren | Modal Step | Bauen | von S02 Zeilenaktion Duplizieren | Subframe: Rolle duplizieren |
|
|
| M02 | Rolle bearbeiten | Grosses Modal | Bauen | von S02 Bearbeiten oder M04A/M04B | Finale Subframe-Seite: M02 Rolle bearbeiten |
|
|
| D03 | Rolle in Nutzung blockiert | Admin Blocker | Nur dokumentieren | von S02/M02 | Validiert |
|
|
| V01 | Letzter Admin blockiert | Admin Blocker | Nur dokumentieren | von S01/M03/Rollenwechsel | Validiert |
|
|
|
|
---
|
|
|
|
## 10. Subframe-Grid
|
|
|
|
```text
|
|
S01 Mitarbeiterliste -> M01 Mitarbeiter einladen
|
|
S01 Mitarbeiterliste -> M03 Mitarbeiter deaktivieren
|
|
S01 Mitarbeiterliste -> V01 Letzter Admin blockiert
|
|
S01 Mitarbeiterliste -> Rolle wechseln inline
|
|
S01 Mitarbeiterliste -> S02 Rollen und Berechtigungen via Dropdown-Eintrag `Rollen und Berechtigungen bearbeiten`
|
|
S02 Rollen und Berechtigungen -> M04A Rolle anlegen via Rolle anlegen
|
|
S02 Rollen und Berechtigungen -> M04B Rolle duplizieren via Duplizieren
|
|
M04A Rolle anlegen -> M02 Rolle bearbeiten
|
|
M04B Rolle duplizieren -> M02 Rolle bearbeiten
|
|
S02 Rollen und Berechtigungen -> M02 Rolle bearbeiten via Bearbeiten
|
|
S02 Rollen und Berechtigungen -> D03 Rolle in Nutzung blockiert
|
|
```
|
|
|
|
### Subframe-Stand M02/M04A/M04B
|
|
|
|
`M02 Rolle bearbeiten` ist die finale Subframe-Seite fuer die Umsetzung. Die alten M02-Referenzvarianten wurden aus Subframe geloescht, damit der Admin-RBAC-Flow clean bleibt. Fuer den M04-Split werden die bestehenden Subframe-Seiten getrennt referenziert: M04A fuer `Rolle anlegen`, M04B fuer `Rolle duplizieren`. Aktueller Subframe-Stand im Admin-RBAC-Flow:
|
|
|
|
| Screen | Subframe |
|
|
|---|---|
|
|
| M02 Rolle bearbeiten | [Subframe](<https://app.subframe.com/f023064a5ca0/design/9a9873e3-d790-4373-b8c2-fadd3b82cbe6/edit>) |
|
|
| M04A Rolle anlegen | [Subframe](<https://app.subframe.com/f023064a5ca0/design/479ee52d-8d73-46e9-9a9b-a8798a22d764/edit>) |
|
|
| M04B Rolle duplizieren | [Subframe](<https://app.subframe.com/f023064a5ca0/design/610d08e6-5c6a-44d3-9b29-220664393ea0/edit>) |
|
|
|
|
---
|
|
|
|
## 11. Screen-Pakete
|
|
|
|
| ID | Datei |
|
|
|---|---|
|
|
| S01 | [[Screens/S01 Mitarbeiterliste]] |
|
|
| M01 | [[Screens/M01 Mitarbeiter einladen]] |
|
|
| D01 | [[Screens/D01 Rollen-Dropdown in Mitarbeiterliste]] |
|
|
| M03 | [[Screens/M03 Mitarbeiter deaktivieren]] |
|
|
| S02 | [[Screens/S02 Rollen und Berechtigungen]] |
|
|
| M04A | [[Screens/M04A Rolle anlegen]] |
|
|
| M04B | [[Screens/M04B Rolle duplizieren]] |
|
|
| M02 | [[Screens/M02 Rolle bearbeiten]] |
|
|
| D03 | [[Screens/D03 Rolle in Nutzung blockiert]] |
|
|
| V01 | [[Screens/V01 Letzter Admin blockiert]] |
|
|
|
|
---
|
|
|
|
## 12. Backlog / V2
|
|
|
|
Diese Punkte sind bewusst nicht Teil der v1-Screen-Liste, sollen aber fuer spaetere Versionen sichtbar bleiben.
|
|
|
|
| Thema | Beschreibung | Warum spaeter |
|
|
|---|---|---|
|
|
| Deaktivieren mit Reassign | Beim Deaktivieren offene Projekte, Aufgaben, Leads, Kunden, Dateien oder Verantwortlichkeiten auf andere Nutzer uebertragen | v1 bleibt bewusst bei kleinem Confirm-Modal |
|
|
| Rollen-Loeschen mit Ersatzrolle | Wenn eine Rolle noch Nutzer hat, Ersatzrolle waehlen und Nutzer gesammelt umziehen | v1 blockiert nur und verlangt manuelle Umzuweisung |
|
|
| Gruppen | Gruppen/Teams/Abteilungen als eigene Verwaltung, ggf. mit Bulk-Zuweisung | fuer v1 aus RBAC rausgenommen |
|
|
| Rechtekatalog als eigener Tab | Alle technischen Berechtigungen unabhaengig von Rollen durchsuchen/erklaeren | v1 zeigt Rechte nur im Rollen-Editor |
|
|
| Rollen-Audit | Historie, wer Rollen/Rechte geaendert hat | Audit-Viewer nicht Teil dieses Pakets |
|
|
| Rollen-Review / Needs Review | Rollen markieren, die geprueft werden muessen, inkl. Review-Zyklus | Status `Pruefen` ist UI-vorbereitet, Prozess spaeter |
|
|
| Rollen-Vorlagen ausarbeiten | branchenspezifische Rollen-Vorlagen fuer neue Rollen definieren | Vorlagen sind aktuell Work in Progress und nicht Teil der initialen Rollenliste |
|
|
| Rechte-Matrix | Vergleich mehrerer Rollen nebeneinander | fuer v1 zu breit/technisch |
|
|
| Bulk-Aktionen | mehrere Mitarbeiter gleichzeitig einladen, deaktivieren oder Rollen zuweisen | spaeter, wenn Teamlisten groesser werden |
|
|
| Admin-Schutz erweitert | detaillierte Regeln fuer Selbst-Deaktivierung, letzter Admin, kritische Rollenwechsel | v1 dokumentiert Blocker, genaue Policy spaeter mit Dev/Security |
|
|
|
|
---
|
|
|
|
## 13. Handoff-Check
|
|
|
|
- [x] Paket ist angelegt.
|
|
- [x] D-P2 Admin-Screens sind geprueft.
|
|
- [x] Gruppen sind fuer dieses Paket rausgenommen.
|
|
- [x] `Admin` als einzige Startrolle plus eigene Rollen sind als Richtung notiert.
|
|
- [x] Rollen-Vorlagen sind als Work in Progress dokumentiert.
|
|
- [x] Permission-Bundles sind als Arbeitsgeruest markiert, nicht als finaler Rechtekatalog.
|
|
- [x] Permission-Zeilenmuster fuer das Rollen-Modal ist dokumentiert.
|
|
- [x] Grober Screen-Aufbau mit Suche/Filtern ist dokumentiert.
|
|
- [x] S01 Mitarbeiterliste ist validiert.
|
|
- [x] M01 Mitarbeiter einladen ist validiert.
|
|
- [x] Rollen-Dropdown in S01 und Sprung zu `Rollen und Berechtigungen` sind dokumentiert.
|
|
- [x] S02 Rollen und Berechtigungen ist validiert.
|
|
- [x] M04A Rolle anlegen ist als eigener Screen vermerkt.
|
|
- [x] M04B Rolle duplizieren ist als eigener Screen vermerkt.
|
|
- [x] M02 Rolle bearbeiten ist validiert.
|
|
- [x] M03 Mitarbeiter deaktivieren ist validiert.
|
|
- [x] D03 Rolle in Nutzung blockiert ist validiert.
|
|
- [x] V01 Letzter Admin blockiert ist validiert.
|
|
- [x] Reassign ist in den Backlog gelegt.
|
|
- [x] Backlog/V2-Liste ist dokumentiert.
|
|
- [x] Permission-Bundles sind fuer v1 als UI-Arbeitsgeruest ausreichend benannt.
|
|
- [x] David hat die Kandidaten validiert.
|
|
- [x] Screen-Dateien sind angelegt und nach Screen-Zuschnitt synchronisiert.
|
|
- [x] Canvas ist angelegt und nach M04-Split synchronisiert.
|
|
- [x] M01/M02/M03/M04A/M04B/D03/V01 sind auf echte Subframe-Dialog-Struktur geprueft: `DialogLayout` -> `Dialog` -> `Dialog.Content`.
|
|
- [x] Subframe-Links sind eingetragen.
|
|
- [x] M04A ist visuell an den final angepassten M04B-Duplikat-Screen angeglichen, aber ohne Duplikat-Modus.
|