Roles & permissions: twee lagen, zeven org roles

Permissions in een multi-tenant ITAD-platform moeten precies juist of zichtbaar fout zijn — er is weinig middenweg. Het permission model van het platform heeft twee lagen: platform-level roles (cross-tenant, voor de platform operator) en org-level roles (per tenant, voor gebruikers van de klant).

Platform-level roles

Drie rollen voor de platform operator: platform_owner (volledige toegang, kan tenantoverschrijdend zien en handelen, beheert billing en platform-wide settings), platform_staff (kan tenantoverschrijdend kijken voor support en adjudication, kan billing of platform-wide settings niet wijzigen), platform_viewer (read-only toegang voor analytics en audit).

Org-level roles

Zeven rollen per tenant: org_admin (volledige toegang binnen de tenant), org_manager (beheert users en settings, kan de org niet verwijderen), org_operator (dagelijks warehouse- en opswerk), org_finance (settlements, invoices, escrow finance views), org_sales (market- en auctionactiviteit, deal rooms), org_viewer (read-only over de org), org_external (beperkte toegang voor het toekomstige client portal — alleen eigen data).

Handhaving in twee lagen

Platformpagina’s (bijv. /admin/platform/trust-scoring) gebruiken getAdminScope() om de platform-level role van de gebruiker te controleren. Org-pagina’s (bijv. /admin/organizations/[slug]) gebruiken dezelfde functie met een andere scope check. Database-level RLS is de finale handhaving: zelfs als een UI-bug een gebruiker ergens laat navigeren waar hij niet hoort, weigeren row-level policies de data terug te geven.

Roltoewijzing

/admin/users (per tenant) laat een org_admin org-level roles toewijzen. /admin/users (platform-level) laat een platform_owner platform-level roles toewijzen. Rolwijzigingen worden audit-gelogd met assigner, timestamp en vorige rol. Self-suspension is geblokkeerd — een org_admin kan zichzelf niet suspenderen en de org buitensluiten.