Überblick
In Ottili ONE sind Berechtigungen und Entitlements nicht auf ein einzelnes Produkt begrenzt. Sie werden unternehmensweit geteilt* und gelten konsistent über alle aktiven Module hinweg*. Zwei Ebenen wirken dabei zusammen:
- Rollen* bestimmen, wer im Unternehmen was sehen und tun darf.
- Entitlements* (Funktionsberechtigungen) bestimmen, welche Funktionen für das Unternehmen überhaupt verfügbar sind.
Beide Ebenen werden immer im Kontext der Firma ausgewertet (company_id). Es gibt keinen globalen, unternehmensübergreifenden Zugriff und keine implizite Ableitung eines Unternehmenskontextes.
Rollen als gemeinsame Grundlage
Ottili ONE arbeitet mit fünf Rollen: Inhaber*, Admin*, Manager*, Mitarbeiter* und Betrachter*. Diese Rollen sind unternehmensweit wirksam — sie gelten nicht nur in einem Modul, sondern in der gesamten Plattform.
Eine Rolle entscheidet zum Beispiel, ob ein Nutzer Module aktivieren, Einstellungen ändern, Datensätze bearbeiten oder nur lesen darf. Die genaue Aufteilung der Rechte je Rolle beschreibt der Artikel [Rollen und Berechtigungen](/docs/roles-and-permissions).
Entitlements: ein geteiltes, mandantenbezogenes Modell
Die Entitlement-Engine* ist die zentrale, unternehmensbezogene Entscheidungsinstanz für Funktionsberechtigungen. Für genau einen expliziten Unternehmenskontext kombiniert sie alle Dimensionen zu einem deny-by-default*-Urteil:
- Tarif des Unternehmens (
plan) - gekaufte Erweiterungen (
purchases, Add-ons) - genehmigte Testphasen (
trials) - Free-Forever-Einbindung
- administrativ vergebene Rechte (
grants) - Region
- Produktstatus (
product status) - Sperrstatus des Unternehmens (
suspension)
Jede Entscheidung ist eine klare Zuweisung mit Zustand, Quelle und Klassifikation:
| Dimension | Werte |
|---|---|
Zustand (GrantState) | ACTIVE_PLAN, ACTIVE_ADDON, ACTIVE_GRANT, ACTIVE_FREE, INACTIVE, CONFLICT, UNKNOWN |
Quelle (GrantSource) | Tarif enthalten, Add-on-Kauf, manueller Grant, Free-Forever |
Klassifikation (GrantClassification) | PLAN_INCLUDED, ADDON_PURCHASE, MANUAL_GRANT, FREE, NONE |
Harte Gates:* Ist ein Unternehmen gesperrt, wird alles verweigert. Ist eine Region nicht erlaubt oder ein Produkt gesperrt, wird die Funktion deny-by-default blockiert. Der Unternehmenskontext wird dabei nie aus einer ersten Mitgliedschaft oder einem globalen Standard abgeleitet — die Auswertung erzwingt den Kontext explizit.
Modul-Aktivierung und Standardberechtigungen
Wenn ein Modul für ein Unternehmen aktiviert wird, vergibt die Plattform dessen Standardberechtigungen* automatisch an die Standardrollen des Unternehmens — an Inhaber*, Admin* und Manager* sowie an jede Rolle, die bereits ein Recht für dieses Modul besitzt. Dadurch ist ein Modul ohne manuellen Freigabe-Rundlauf sofort nutzbar.
Bei Deaktivierung oder Entfernung eines Moduls werden diese Standardberechtigungen wieder entzogen. Alle Vergaben sind:
- eindeutig mandantenisoliert* — jeder Datensatz trägt
company_id; - idempotent* — eine wiederholte Aktivierung erzeugt keinen doppelten Grant;
- nachvollziehbar* — Entzug bei Deaktivierung wird protokolliert, nicht still überschrieben.
Gemeinsame Geltung über Module hinweg
Ein Nutzer mit einer bestimmten Rolle und ein Unternehmen mit bestimmten Entitlements erleben dieselbe Berechtigungsgrundlage in jedem aktiven Modul*. Module teilen sich den Unternehmenskontext; Berechtigungen werden nicht pro Modul neu erfunden. Das bedeutet: Wer im Business Hub Daten bearbeiten darf, tut dies im Rahmen derselben Rolle wie in allen anderen Modulen.
Freigaben für sensible Aktionen
Manche Aktionen erfordern eine menschliche Freigabe, bevor sie ausgeführt werden. Sie landen in der Genehmigungs-Queue*, wo eine berechtigte Person gegenzeichnet. Das gilt sowohl für menschliche Nutzer als auch für automatisierte Abläufe. Mehr dazu im Artikel [Die Genehmigungs-Queue](/docs/approval-queue).
Support-KI im Berechtigungsrahmen
Ottili KI agiert strikt innerhalb der vergebenen Berechtigungen. Sie kann nur die Daten, Tools und Module lesen, mit denen sie verbunden ist, und niemals eine freigabepflichtige Aktion ausführen, ohne dass ein Mensch gegenzeichnet. Der Berechtigungsrahmen gilt also auch für die KI.
Status klar unterscheiden
Funktionen und Produkte durchlaufen klare Statusstufen. Die Entitlement-Engine spiegelt den Produktstatus wider: ein gesperrtes Produkt wird deny-by-default blockiert.
| Status | Bedeutung |
|---|---|
| Live* | Allgemein verfügbar. |
| Beta* | Öffentlich testbar, kann noch reifen. |
| Private Beta* | Eingeschränkt verfügbar, nur auf Einladung. |
| In Entwicklung* | In Arbeit, noch nicht veröffentlicht. |
| Geplant* | Vorgesehen, aber noch nicht begonnen. |
| Konzept* | Frühe Idee, kein Lieferversprechen. |
Verwandte Artikel
- [Rollen und Berechtigungen](/docs/roles-and-permissions)
- [Die Genehmigungs-Queue](/docs/approval-queue)
- [Unternehmen und Team](/docs/company-and-team)
- [Workspace und Module](/docs/workspace-and-modules)
War dieser Artikel hilfreich?
