Rollen & Rechte: zwei Ebenen, sieben Org-Rollen
Platform-Rollen, Tenant-Rollen, eine gemeinsame Matrix — und warum der Modulzugang nicht davon abhängt, wer zuletzt seinen Profilnamen geändert hat.
Berechtigungen in einer Multi-Tenant-ITAD-Plattform müssen präzise stimmen, sonst sind sie sichtbar falsch. Dazwischen liegt wenig Brauchbares. ReVend OS nutzt zwei Ebenen: Platform-Rollen für den ReVend-Betrieb und Organisationsrollen für die User eines Tenants.
Rollen auf Platform-Ebene
platform_owner verwaltet die Plattform von vorne bis hinten. platform_staff betreut Kunden und arbeitet tenantübergreifend, soweit der Support- und Admin-Flow das zulässt. platform_viewer ist read-only für die Aufsicht. Platform-Seiten prüfen den Platform-Scope, bevor sie platform-only Tools wie Health, Package-Pläne oder Trust-Scoring-Einstellungen zeigen.
Rollen auf Org-Ebene
Heute sind sieben Tenant-Rollen im Einsatz: org_admin, org_manager, org_warehouse, org_commercial, org_finance, org_operator und org_viewer. Sie beschreiben, was jemand innerhalb des Tenants tatsächlich tut. Package-Entitlements entscheiden, welche Module der Tenant gekauft hat; die Rolle entscheidet, welches dieser Module eine Person öffnen darf. Beide Prüfungen laufen, in genau dieser Reihenfolge, und ein Tab erscheint erst, wenn beide Ja sagen.
Eine Matrix, drei Leser
Welche Rolle welches Modul öffnen darf, steht in einer einzigen Matrix im Code, und die Modul-Tabs, die Sidebar, die Command Palette und die serverseitigen Page Guards lesen alle dieselbe Matrix. Market, Auction und Sourcing öffnen für Administrator, Manager und Vertrieb. Escrow öffnet für Administrator und Finanzen. Finance — Invoices, Settlements, Margen — öffnet für Administrator, Manager und Finanzen. Testing öffnet für Administrator, Manager, Lager und Operator. Dashboard, Core, General, Settings und Support stehen jeder Organisationsrolle offen. Platform-Support umgeht die Matrix vollständig, weil Impersonation und Supportarbeit jede Seite erreichen können müssen. Vor der Matrix wusste die Navigation, was der Tenant gekauft hatte, und die Page Guards wussten, was die Rolle durfte, und die beiden sind sich nie begegnet: Ein User mit der Rolle Finanzen hatte einen klickbaren Market-Tab, der in einem nackten 404 endete. Eine Matrix, drei Leser. Keine Tabs mehr ins Nirgendwo.
Ausgeblendet statt 404
Ein Modul, das Ihre Rolle nicht öffnen darf, steht schlicht nicht in der Navigation. Ein User mit der Rolle Finanzen sieht Market, Auction und Sourcing nicht; ein User mit der Rolle Vertrieb sieht Escrow nicht. Auch Settings-Seiten für Module, die der Tenant gar nicht hat, verschwinden aus dem Menü, statt auf die Subscription-Seite zu springen. Wer über ein Lesezeichen, einen E-Mail-Link oder eine alte Verknüpfung trotzdem dort landet, bekommt eine Erklärung: um welches Modul es geht, dass diese Rolle es nicht öffnen darf, welche Rollen es dürfen, und einen Button zurück zum Dashboard. Tenantweite Einstellungen, die dem Organisations-Admin vorbehalten sind — Billing, Geschäftszeiten, Analytics-Schwellen — bleiben für alle sichtbar, öffnen für andere Rollen aber mit dem Hinweis „Von Ihrer Administratorin verwaltet“. Eine Seite, die sich selbst erklärt, kostet einen Absatz; ein 404 kostet ein Supportticket.
Operator ist die Voreinstellung
Operator ist die Rolle, die eine Einladung mitbringt, solange der Einladende keine andere wählt, und es ist die Rolle, die die Testarbeit erledigt: Der Testbildschirm steht Administrator, Manager, Lager und Operator offen. Bei Contracts läuft es andersherum — einen Contract anlegen und bearbeiten, seine Services und Rates, seine Pflichtzertifizierungen und die unterschriebene Vereinbarung sind Administrator, Manager und Vertrieb vorbehalten, demselben Kreis, der einen Contract aktivieren darf. Lager, Operator, Finanzen und Betrachter lesen Contracts; sie sehen keinen Button zum Bearbeiten, keinen zum Verwalten und keinen „Neuer Vertrag“, und ein direkter Server-Call wird abgewiesen und als Access denied protokolliert.
Wo durchgesetzt wird
Die Navigation ist hilfreich, aber Server und Datenbank sind die Erwachsenen im Raum. Server Guards lesen Rollen aus Membership-Records, nicht aus editierbaren User-Metadaten. RLS hält Tenantdaten im Tenant. Service-Role-Code im Admin muss den Tenant-Scope explizit setzen, weil Service Role RLS umgeht; das ist Macht mit Papierkram, keine Abkürzung.
Admin-Grenzen
Admin-Seiten sind platform-only: Platform-Rollen sehen tenantübergreifende Platform-Tools, und Nicht-Platform-User werden aus Admin herausgeleitet. Tenant-Profil und Teamverwaltung liegen in Settings unter /settings/organization-profile und /settings/users. Eine fehlende Route ist ärgerlich; ein geleaktes tenantübergreifendes Tool ist ein Alarm.
Änderungen und Audit
Rollen- und Rechteänderungen sind audit-relevant. Die Plattform hält fest, wer den Zugriff geändert hat, was sich geändert hat und warum. Wenn ein User plötzlich weniger Buttons sieht, sollte der Support das erklären können, ohne im Browser-Cache Kaffeesatz zu lesen.