Rollen & Capabilities
Diese Seite beschreibt das Rollen- und Berechtigungsmodell auf technischer Ebene. Sie richtet sich an Entwickler. Die nutzerorientierte Variante steht unter Rollen & Berechtigungen.
Zwei Rollen-Achsen
Abschnitt betitelt „Zwei Rollen-Achsen“KanzleiSynchron unterscheidet zwei Achsen (backend/api/src/auth.rs):
- Mandanten-Rollen — Nutzer eines Mandanten. Sichtbar im Einladungsformular unter
/settings/team. - Interne Ops-Rollen — KS-internes Personal. Zugriff nur über
/ops/**, keine Mandanten-Nutzer.
Mandanten-Rollen
Abschnitt betitelt „Mandanten-Rollen“Beim Einladen unter /settings/team stehen genau diese drei Rollen zur Auswahl (frontend/src/app/(app)/settings/team/page.tsx):
| Rollen-Schlüssel | Anzeigename | Darf |
|---|---|---|
reviewer | Sachbearbeiter / Mitarbeiter | Tägliche Arbeit: Importe, Abstimmung, Ausnahmen. Kein Team-Management, keine Einstellungsänderung. |
merchant_admin | Kanzlei-Admin | Team einladen/sperren, Mandanteneinstellungen ändern, Löschung (Erasure) auslösen. Eigentümer eines Mandanten. |
internal_ops | Interner Operator | Mandantenübergreifende Sichtbarkeit. Wird zur Einladungszeit von einem merchant_admin vergeben. |
Capability-Helfer (Frontend)
Abschnitt betitelt „Capability-Helfer (Frontend)“Das Frontend gated Admin-Oberflächen über frontend/src/lib/role-capabilities.ts statt über harte Rollen-Vergleiche:
| Helfer | Erlaubt für |
|---|---|
canViewAdmin(r) | super_admin, support, compliance_officer, read_only, merchant_admin |
canMutateTenant(r) | super_admin, merchant_admin |
canManageTeam(r) | super_admin, merchant_admin |
canRunErasure(r) | super_admin, compliance_officer, merchant_admin |
Zusätzlich liefert /me ein capabilities: string[]-Array. Ops-Nutzer haben role: null und ein separates ops_role, weshalb rollenbasierte Gates für sie fail-closed sind; verwende daher hasCapability(caps, cap) mit den Konstanten aus OPS_CAPS / TENANT_CAPS.
Interne Ops-Rollen (Backend)
Abschnitt betitelt „Interne Ops-Rollen (Backend)“Vier abgestufte interne Rollen ersetzen das frühere breite internal_ops (backend/api/src/auth.rs, Sprint 10 §13.2). merchant_admin bleibt als Migrationspfad in allen Ops-Gates zugelassen.
| Rolle | Mandanten | DPR / Erasure | Issues | Mutieren? |
|---|---|---|---|---|
super_admin | ja | ja | ja | ja |
support | lesen | nein | ja | Issues |
compliance_officer | lesen | ja | lesen | DPR |
read_only | lesen | lesen | lesen | nein |
Die Backend-Gates dazu:
require_super_admin—super_admin(plusmerchant_adminfür Kompatibilität).require_support—super_adminodersupport.require_compliance—super_adminodercompliance_officer(DPR-Akten, DSGVO-Art.-17-Löschung).require_read_only_ok— alle Ops-Rollen dürfen lesende GETs;read_onlyscheitert an den mutierenden Gates.
OPS_ROLES umfasst super_admin, support, compliance_officer, read_only und das aus Kompatibilitätsgründen geführte internal_ops.
Vier-Augen-Prinzip
Abschnitt betitelt „Vier-Augen-Prinzip“Der Periodenabschluss erfordert, dass eine andere Person abschließt als die, die die Periode angelegt hat. Daraus folgt: Ein Mandant braucht mindestens zwei Nutzer mit Zugriff, sonst lässt sich der Abschluss nicht durchführen. Mehr dazu unter Rollen & Berechtigungen.