Berechtigungen und Permission-Editor

SpeamCore nutzt CASL als Berechtigungs-Modell — eine flexible Rule-Engine die definiert, welcher Anwender welche Aktion auf welchem Datentyp ausführen darf. Diese Anleitung zeigt Ihnen, wie Sie das verwalten.

Wann mache ich das?

• Bei neuen Rollen-Anforderungen — Standard-Rollen reichen nicht.
• Bei Sicherheits-Audit — Berechtigungen prüfen.
• Bei Mitarbeiter-Wechseln — Rollen anpassen.
• Bei Mandanten-Setup — Initial-Rollen-Schema.

i

Voraussetzung

• Sie sind mit Admin-Account in SpeamCore eingeloggt.
• Sie verstehen das CASL-Modell (siehe Berechtigungen-CASL Konzept).
• Bei kritischen Änderungen Vier-Augen-Prinzip.

Konzept

Anwender (Mitarbeiter)
  └─ hat Rolle(n)
       └─ enthält CASL-Rules
            ├─ Action (view, create, update, delete, custom: do:Approve)
            ├─ Subject (Customer, Workorder, ... ~430 Subjects)
            └─ Optional: Conditions (z.B. nur eigene Datensätze)

Jeder Request prüft das Backend: hat der User die nötige Permission? Wenn nein → 403 Forbidden.

So verwalten Sie Berechtigungen

1

Permission-Editor öffnen

In der Sidebar Permission-Editor. Sie sehen die UI-Sicht aller verfügbaren Subjects und Actions.

Zwei Workflows:

• Über Rolle (typisch) — Rolle auswählen, Berechtigungen pro Subject setzen.
• Über Subject (selten) — Subject auswählen, sehen welche Rollen es nutzen.

2

Bestehende Rolle bearbeiten

In der Sidebar Rollen → Rolle auswählen → Tab Berechtigungen.

Pro Subject + Action eine Checkbox:

• view — darf lesen.
• create — darf neu anlegen.
• update — darf ändern.
• delete — darf löschen.
• do:CustomAction — spezielle Aktionen (z.B. do:ApproveAbsence).

Häkchen setzen → speichern.

KI

Restriktiv beginnen

Lieber zu wenig Rechte vergeben und auf Anfrage erweitern als zu viel und nachträglich entziehen. Datenschutz: Mitarbeiter sollten nur sehen was sie für ihre Rolle brauchen.

3

Custom-Rolle anlegen

+ Rolle hinzufügen:

1. Name — aussagekräftig („Senior-Servicetechniker", „Junior-Buchhalter").
2. Beschreibung — was die Rolle umfasst.
3. Berechtigungen — pro Subject + Action setzen.
4. Speichern.

Custom-Rollen können Mitarbeitern zusätzlich zu Standard-Rollen zugewiesen werden.

4

Conditions — feinere Kontrolle

Manche Berechtigungen brauchen Conditions — zum Beispiel „darf nur eigene Aufträge sehen" statt „darf alle Aufträge sehen".

In der Permission-Editor-UI:

• Pro Berechtigung ein Conditions-Feld.
• Beispiel: { employeeId: '$user.id' } → nur eigene Datensätze.
• { status: 'open' } → nur offene Datensätze.

Conditions werden Backend-seitig durchgesetzt — Frontend zeigt nur passende Datensätze.

5

FE_-Subjects — Frontend-Page-Guards

In SpeamCore unterscheidet CASL zwei Subject-Typen:

• API-Subjects (z.B. Customer) — Datenzugriff im Backend.
• FE_Subjects (z.B. FE_Customer) — Sichtbarkeit der Seite im Frontend.

Eine Rolle braucht beide für den vollen Zugriff:

• view:FE_Customer — Seite ist sichtbar.
• view:Customer — Daten werden geladen.

Bei nur einem fehlt entweder die Seite (404) oder die Seite ist da, zeigt aber „Keine Daten" trotz Bestand.

Was tue ich, wenn etwas schiefgeht?

!

Mitarbeiter sieht plötzlich nichts mehr

Berechtigungen prüfen — vielleicht ist FE_-Subject nicht aktiviert. Oder Rolle wurde versehentlich entzogen.

!

Custom-Action fehlt im Editor

Custom-Actions (do:Approve etc.) müssen Backend-seitig definiert sein. Bei fehlender: Entwickler-Team einbeziehen.

!

Berechtigungen funktionieren nicht trotz Häkchen

Cache leeren (Hard-Reload), Mitarbeiter ggf. neu einloggen. Bei wiederholtem Problem Logs prüfen.

Tipps

• Halbjährliches Audit — alle Custom-Rollen prüfen, ob noch nötig.
• Standard-Rollen bevorzugen — Custom-Rollen führen zu Wildwuchs.
• Vier-Augen bei Admin-Rollen — niemand sollte allein Admin-Rechte verteilen.
• Test-Account pro Rolle — bei größeren Mandanten Test-User mit jeder Rolle, um neue Konfigurationen zu prüfen.

Verwandte Tutorials

• Abteilungsstruktur und Rollen pflegen (HR-Leitung) — operative Rollen-Vergabe
• Berechtigungen-CASL (Konzept)

Für Entwickler: technische Details

• Permission-Editor-Modul: /permission-editor.
• Rollen-Modul: /roles.
• CASL-Subjects ~430, definiert im FE-Repo src/config/auth/casl.ts.
• Backend nutzt eigene CASL-Implementation (caslMiddleware) zur API-Validierung.
• Conditions-Sprache: MongoDB-ähnlich (z.B. $or, $gt, $user.id).
• Audit: alle Berechtigungs-Änderungen werden im Audit-Log protokolliert.