Rôles & permissions: deux couches, sept org rôles
Rôles platform-level, rôles org-level, et comment le système decide si vous pouvez voir trust-scoring config ou company financials.
Les permissions dans une plateforme ITAD multi-tenant doivent être précisément correctes ou visiblement fausses — il y a très peu d’entre-deux. Le modèle de permissions de la plateforme a deux couches : rôles platform-level (cross-tenant, pour l’opérateur plateforme) et rôles org-level (par tenant, pour les utilisateurs du client).
Platform-level rôles
Trois rôles pour l’opérateur plateforme : platform_owner (accès complet, peut voir et agir sur tous les tenants, gère billing et platform-wide settings), platform_staff (peut voir entre tenants pour support et adjudication, ne peut pas changer billing ou platform-wide settings), platform_viewer (accès read-only pour analytics et audit).
Org-level rôles
Sept rôles par tenant : org_admin (accès complet dans le tenant), org_manager (gère users et settings, ne peut pas supprimer l’org), org_operator (travail warehouse et ops au quotidien), org_finance (settlements, invoices, vues escrow finance), org_sales (activité market et auction, deal rooms), org_viewer (read-only dans l’org), org_external (accès limité pour le futur client portal — restreint à ses propres données).
Enforcement en deux couches
Les pages plateforme (par ex. /admin/platform/trust-scoring) utilisent getAdminScope() pour vérifier le rôle platform-level de l’utilisateur. Les pages org (par ex. /admin/organizations/[slug]) utilisent la même fonction avec un scope check différent. La RLS au niveau database est l’enforcement final : même si un bug UI laisse un utilisateur naviguer quelque part où il ne devrait pas, les row-level policies refusent de retourner les données.
Attribution des rôles
/admin/users (par tenant) permet à un org_admin d’assigner les rôles org-level. /admin/users (platform-level) permet à un platform_owner d’assigner les rôles platform-level. Les changements de rôle sont audit-logged avec l’assigner, le timestamp et l’ancien rôle. L’auto-suspension est bloquée — un org_admin ne peut pas se suspendre lui-même et verrouiller l’org dehors.