--- 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]() | | M04A Rolle anlegen | [Subframe]() | | M04B Rolle duplizieren | [Subframe]() | --- ## 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.