Berechtigungen & Scopes

Die Autorisierung in Codemeta OS läuft in zwei Stufen. Beide müssen passen, damit ein Request durchgeht.

Stufe 1: Funktionale Permissions

Permissions sind rollenbasiert und steuern, was ein Account tun darf. Beispiele:

• ticket_view, ticket_create, ticket_update, ticket_delete
• kb_article_publish, kb_article_archive
• billing_manage, customer_tenant_manage
• admin_bypass – umgeht alle Checks (nur für interne Admin-Konten)

Permissions kommen aus den Rollen, die einem Account in einem Mandanten zugeordnet sind. Permission-Änderungen werden zeitnah wirksam.

Stufe 2: Datenscopes

Datenscopes steuern, welche Datensätze ein Account sehen oder ändern darf. Mögliche Werte:

• all – alle Datensätze des Mandanten
• assigned_to – nur Datensätze, in denen der Account als Bearbeiter eingetragen ist
• team_member – Datensätze, deren Team der Account angehört
• customer_contact – Datensätze, an denen der Account als Kunden-Kontakt verknüpft ist
• created_by – nur eigene erstellte Datensätze

Welcher Scope greift, hängt von der Entity ab. Tickets unterstützen alle fünf, Verträge oft nur all und assigned_to.

Conditional Mode

Manche Entities erlauben konditionale Scopes – verschiedene Regeln je nach Feldwert. So lässt sich etwa formulieren: „Ich sehe alle Rechnungen, aber nur meine eigenen Ticket-Anhänge“. Konditionale Scopes referenzieren ein scopeableField aus der Entity-Konfiguration.

Reihenfolge der Prüfung

1. Hat der Account Permission für die Operation? Wenn nicht → 403.
2. Greift der Datenscope auf den angeforderten Datensatz? Wenn nicht → 403.
3. Bei admin_bypass: beide Prüfungen werden übersprungen.

Permissions und Module

Manche Permissions sind nur sinnvoll, wenn der Mandant ein bestimmtes Modul lizenziert hat (z. B. lms_course_publish ohne LMS-Lizenz). Das Lizenz-Gate greift vor der Permission-Prüfung – Sie bekommen dann 402 Payment Required mit type=https://codemeta-os.de/probs/license-required.

Verwandte Konzepte

• Multi-Tenancy
• Plattform-Garantien