Rollen & Berechtigungen

Die Zugriffskontrolle (RBAC) basiert auf Berechtigungen im Schema modul:aktion (z.B. okr:write, person:read, risk:delete, admin:tenant). Eine Rolle bündelt Berechtigungen. Rollen werden pro Mandant definiert und zugewiesen — derselbe Benutzer kann in einem Mandanten Tenant-Admin und in einem anderen nur Beobachter sein.

Standard-Rollen

Jeder Mandant erhält automatisch vier System-Rollen. Diese sind bearbeitbar, aber nicht löschbar:

Tenant-Admin — volle Verwaltung innerhalb des Mandanten (admin:tenant).
Benutzer — lesen und bearbeiten, kein Löschen oder Administrieren. Über person:write pflegt diese Rolle auch die Abwesenheiten einer Person.
Beobachter — ausschließlich Lesezugriff. Kann nichts bearbeiten.
Sicherheitsbeauftragter — Lesezugriff plus Sichtbarkeits-Verwaltung.

Plattform-Administrator ist eine globale Rolle (mandantenübergreifend) und steht außerhalb dieses Modells — sie hat überall Vollzugriff.

Die Mandantengrenze gilt für alle anderen ausnahmslos. Ein Tenant-Admin verwaltet ausschließlich seinen eigenen Mandanten; ein Sicherheitsbeauftragter sieht innerhalb seines Mandanten auch eingeschränkte Inhalte, aber ebenfalls nichts von anderen Mandanten. Wer in mehreren Mandanten arbeitet, wechselt dafür den Mandanten (oben rechts) — die Rechte richten sich immer nach dem gerade aktiven. Das gilt auch beim direkten Aufruf über eine bekannte Adresse oder Objekt-ID: Inhalte eines fremden Mandanten werden abgelehnt, unabhängig von der Rolle.

Benutzerdefinierte Rollen — Beispiel „Vorschlagen ohne Schreibrecht”

Neben lesen/schreiben/löschen gibt es je Fachmodul die Aktion „Entwurf” (modul:draft). Sie erlaubt, einen Änderungsvorschlag (Entwurf) einzureichen, der erst nach Freigabe wirksam wird — ohne direktes Schreibrecht auf dem Modul. Damit lässt sich z.B. eine „Contributor”-Rolle bauen: Lesezugriff plus „Entwurf”, aber kein „Schreiben” — diese Person kann Änderungen vorschlagen, aber nichts direkt übernehmen. Wer bereits „Schreiben” oder „Löschen” hat, darf automatisch auch Entwürfe anlegen — die Berechtigung ist rein additiv. Legen Sie eine solche Rolle wie jede andere benutzerdefinierte Rolle an (siehe unten).

Beziehungen: beide Enden zählen

Eine Beziehung verbindet zwei Objekte, und die Berechtigung wird für beide Enden geprüft. Wer eine Rolle mit einem Vorhaben verknüpfen will, braucht „Entwurf” (oder „Schreiben”) in beiden Modulen — sonst lehnt roleALPHA den Vorschlag ab.

Das gilt auch dann, wenn ein Ende noch gar nicht veröffentlicht ist. Legen Sie ein Vorhaben samt Zuständigkeit in einem Zug an, entsteht die Verknüpfung, während das Vorhaben selbst noch ein Entwurf ist — geprüft wird trotzdem das Modul, zu dem es gehören wird. Lässt sich das nicht feststellen (etwa weil ein Ende weder existiert noch als Entwurf vorliegt), wird der Vorschlag abgelehnt statt durchgelassen.

Übergreifende Berechtigungen

Neben den Modul-Berechtigungen gibt es einige, die quer zu allen Modulen liegen — darunter approval:admin: Entwürfe freigeben, unabhängig vom eingestellten Freigabemodus (siehe Freigabe-Modi). Sie steckt bereits in der Rolle Tenant-Admin, lässt sich aber auch einer eigenen Rolle zuweisen, wenn jemand freigeben können soll, ohne sonst Admin zu sein. Sie wirkt nur im jeweiligen Mandanten, in dem die Rolle zugewiesen ist.

Zuschaltbare Leistungen

Einige Leistungen werden getrennt gebucht oder getrennt eingeschaltet und tragen deshalb ein eigenes Recht — sie stehen im Dialog in einem eigenen Block unter der Modul-Matrix:

Berechtigung	Erlaubt	Verfügbar, wenn
`foresight:read`	Berichte des Proberaum lesen	der Proberaum gebucht ist
`foresight:run`	einen Proberaum-Lauf starten	der Proberaum gebucht ist
`demand:plan`	Bedarf zuweisen und Kapazität planen	der Mandant das Modul Bedarf führt
`timetracker:report`	fremde/aggregierte Aufwands-Auswertungen	die Aufwandserfassung eingeschaltet ist
`validator:report`	Governance-Befunde an einer Entität	der Validator eingeschaltet ist
`demand:report`	Bedarf, Deckung und Kompetenzlücke an einer Entität	der Mandant das Modul Bedarf führt
`okr:report`	Fortschritt der bedienten OKRs an einer Entität	der Mandant das Modul OKR führt

Die Trennung von foresight:read und foresight:run ist Absicht: Lesen kostet nichts, Starten kostet je Lauf Geld und lässt sich nicht rückgängig machen. Geben Sie das Lesen breit und das Starten eng.

Wer eigene Aufwände bucht oder sehen will, worauf er selbst geplant ist, braucht keines dieser Rechte — das geht ohne Rollenzuweisung.

Wer darf die Struktur konfigurieren?

Manches ist keine Fachdaten-Änderung, sondern eine Änderung am Bauplan des Mandanten. Dafür genügt kein Modul-Schreibrecht — nötig ist admin:tenant, also die Rolle Tenant-Admin oder eine eigene Rolle mit dieser Berechtigung:

Vorgang	Nötig
Entitätstypen anlegen, ändern, migrieren, löschen	`admin:tenant`
Beziehungstypen anlegen, ändern, übersetzen, löschen	`admin:tenant`
Constraints der Beziehungsmatrix setzen	`admin:tenant`
Rollendefinitionen und Rollenzuweisungen ändern	`admin:tenant`

Lesen bleibt für alle offen: Entitäts- und Beziehungstypen sind das Fachvokabular, das jede Ansicht zum Anzeigen braucht.

Eine Ebene darüber liegen die Plattform-Vorgänge, für die auch ein Tenant-Admin nicht ausreicht — sie brauchen platform_admin:

Mandanten anlegen, umbenennen, eine eigene Domain setzen oder löschen
Realms (Mandanten-Gruppen) verwalten
Die Mandantenliste der gesamten Plattform einsehen

Ein Tenant-Admin sieht in der Mandantenliste ausschließlich die Mandanten, denen er zugeordnet ist, und verwaltet dort deren Einstellungen und Branding.

Rollen verwalten

Unter Einstellungen → Benutzer & Zugriff → Rollen & Rechte sehen Sie alle Rollen als Liste — analog zu den Fachservice-Daten. Erstellen und Bearbeiten laufen über ein Dialogfenster:

Neue Rolle: Schaltfläche oben rechts → Dialog → Schlüssel (z.B. hr_manager, Kleinbuchstaben/Unterstrich) und Anzeigename vergeben, dann die Berechtigungs-Matrix (Module × Aktionen) setzen → Speichern.
Bearbeiten: Stift-Symbol in der Zeile → derselbe Dialog mit vorbelegter Matrix → Häkchen anpassen → Speichern.
Aktiv-Schalter im Dialog: eine Rolle vorübergehend deaktivieren, ohne sie zu löschen.
Löschen: nur bei eigenen Rollen (Papierkorb in der Zeile); System-Rollen sind geschützt.

Leistungen, die für Ihren Mandanten nicht gebucht sind, erscheinen im Block Zuschaltbare Leistungen trotzdem — aber ausgegraut und nicht anhakbar, mit dem Hinweis „Für diesen Mandanten nicht gebucht”. So sehen Sie, was es gibt, ohne ein Recht vergeben zu können, das die Anwendung ohnehin abweisen würde. Ausnahme: trägt eine Rolle so ein Recht bereits (etwa nach einer Vertragsänderung), bleibt das Häkchen sichtbar und lässt sich abwählen — es geht beim Speichern nie stillschweigend verloren.

Plattform-Administratoren können dieselbe Verwaltung für jeden Mandanten über das Platform-Admin-Dashboard (Services / Health → Rollen) durchführen.

Rollen an Benutzer zuweisen

Ein Benutzer kann beliebig viele Rollen je Mandant haben — seine effektiven Berechtigungen sind die Vereinigung aller zugewiesenen Rollen.

Im Tenant (Benutzerverwaltung): beim Benutzer auf das Schild-Symbol („Rollen zuweisen”) klicken → Mehrfachauswahl der Rollen → Speichern.
Im Platform-Admin (Users): Schaltfläche Rollen beim Benutzer → zuerst den Mandanten wählen, dann die Rollen für diesen Mandanten zuweisen.

platform_admin bleibt davon unberührt — es ist die globale Plattform-Rolle und wird separat über „Rolle ändern” gesetzt.

Wirkung & Hinweise

Entzogene Berechtigungen greifen nach der nächsten Token-Aktualisierung (spätestens beim erneuten Anmelden bzw. Mandantenwechsel).
Beim Mandantenwechsel wird ein neues Token mit der Rolle des Zielmandanten ausgestellt.
Die Rollenzuweisung pro Benutzer erfolgt in der Benutzerverwaltung.