ADR-0007 – Rollen- und Permission-Modell

Status

Accepted (seit Initial-Schema 001, erweitert um user_permissions).

Kontext

Handwerksbetriebe brauchen einfache, verständliche Rollen (Chef/Büro/Monteur), aber gelegentlich feinere Ausnahmen pro Person. Tenancy (Mandantentrennung) muss zwingend serverseitig garantiert sein – über Web und WhatsApp-Agent hinweg.

Entscheidung

• Drei numerische Rollen: 1 = Administrator, 2 = Manager, 3 = Mitarbeiter (kleiner = höher privilegiert). Speicherung in users.role und memberships.role.
• Default-Permissions je Rolle (DEFAULT_ROLE_PERMISSIONS in src/lib/permissions.ts); admin:all (Rolle 1) überschreibt alle Einzelchecks.
• Pro-User-Overrides in user_permissions (resource + mask-Bitmaske) für Ausnahmen.
• Feingranulare Checks über src/lib/authz.ts (can(actor, resource, action, scope)), inkl. „eigener Datensatz"-Regel.
• Serverseitige Durchsetzung zentral in @work7/domain (requireRole, requireTenantScope) – identisch für API und Agent (siehe adr-0002-shared-domain-layer).
• JWT-Session kurzlebig (4 h), trägt role/permissions/roleVersion für schnelle Invalidierung.
• Middleware schützt /admin/** (nur Rolle 1) und Kernbereiche.

Konsequenzen

• ➕ Einfaches mentales Modell für KMU; Ausnahmen ohne neue Rollen möglich; konsistente Tenancy über alle Kanäle.
• ➖ Drei Rollen sind grob – komplexe Org-Strukturen (Abteilungen/Vertretungen) nur teilweise abbildbar (memberships.department_id/manager_id vorhanden, aber wenig genutzt).
• ➖ 2FA-Spalten existieren, sind aber nicht erzwungen.

Verwandte Notes

• 01-auth-onboarding-rbac · 16-team-team-boards · adr-0002-shared-domain-layer