Roles & Permissions: zwei Ebenen, sieben Org Roles

Permissions in einer Multi-Tenant-ITAD-Plattform müssen präzise richtig oder sichtbar falsch sein — dazwischen gibt es wenig. Das Permission Model der Plattform ist zweischichtig: platform-level roles (cross-tenant, für den Plattformbetreiber) und org-level roles (pro Tenant, für die Users des Kunden).

Platform-level roles

Drei Rollen für den Plattformbetreiber: platform_owner (voller Zugriff, kann über alle Tenants sehen und handeln, verwaltet Billing und platform-wide settings), platform_staff (kann tenantübergreifend für Support und Adjudication sehen, kann Billing oder platform-wide settings nicht ändern), platform_viewer (read-only Zugriff für Analytics und Audit).

Org-level roles

Sieben Rollen pro Tenant: org_admin (voller Zugriff innerhalb des Tenants), org_manager (verwaltet Users und Settings, kann die Org nicht löschen), org_operator (tägliche Warehouse- und Ops-Arbeit), org_finance (settlements, invoices, escrow finance views), org_sales (market- und auction activity, deal rooms), org_viewer (read-only über die Org), org_external (begrenzter Zugriff für das spätere Client Portal — nur auf eigene Daten beschränkt).

Zweischichtige Enforcement

Platform Pages (z. B. /admin/platform/trust-scoring) nutzen getAdminScope(), um die platform-level role des Users zu prüfen. Org Pages (z. B. /admin/organizations/[slug]) nutzen dieselbe Funktion mit einem anderen Scope Check. Database-level RLS ist die finale Enforcement: Selbst wenn ein UI Bug einen User irgendwohin navigieren lässt, wo er nicht sein sollte, verweigern die row-level policies die Daten.

Rollenzuweisung

/admin/users (per-tenant) lässt einen org_admin org-level roles zuweisen. /admin/users (platform-level) lässt einen platform_owner platform-level roles zuweisen. Role Changes werden audit-logged mit Assigner, Timestamp und vorheriger Rolle. Self-suspension ist blockiert — ein org_admin kann sich nicht selbst suspendieren und die Org aussperren.