Rôles et permissions : deux couches, sept rôles tenant

Les permissions dans une plateforme ITAD multi-tenant doivent être exactement justes, ou visiblement fausses. L’entre-deux n’a pas grand-chose d’utile à offrir. ReVend OS utilise deux couches : des rôles au niveau plateforme pour l’opérateur ReVend, et des rôles organisation pour les utilisateurs tenant.

Rôles au niveau plateforme

platform_owner gère la plateforme de bout en bout. platform_staff assiste les clients et travaille entre tenants là où le flow support/admin l’autorise. platform_viewer est en lecture seule pour la supervision. Les pages plateforme vérifient la portée plateforme avant d’afficher les outils platform-only comme la santé du système, les plans de package ou les réglages de trust-scoring.

Rôles au niveau organisation

Sept rôles tenant sont utilisés aujourd’hui : org_admin, org_manager, org_warehouse, org_commercial, org_finance, org_operator et org_viewer. Ils décrivent le métier de l’utilisateur à l’intérieur du tenant. Les entitlements de package décident quels modules le tenant a achetés ; le rôle décide lequel de ces modules une personne peut ouvrir. Les deux contrôles tournent, dans cet ordre, et un onglet n’apparaît que si les deux disent oui.

Une matrice, trois lecteurs

Quel rôle peut ouvrir quel module vit dans une seule matrice dans le code, et les onglets de module, la sidebar, la command palette et les gardes de page côté serveur lisent tous cette même matrice. Market, Auction et Sourcing s’ouvrent pour administrateur, manager et commercial. Escrow s’ouvre pour administrateur et finance. Finance — factures, settlements, marges — s’ouvre pour administrateur, manager et finance. Testing s’ouvre pour administrateur, manager, entrepôt et opérateur. Dashboard, Core, General, Paramètres et Support sont ouverts à tous les rôles organisation. Le support plateforme contourne entièrement la matrice, parce que l’impersonation et le travail de support doivent pouvoir ouvrir chaque page. Avant l’existence de la matrice, la navigation savait ce que le tenant avait acheté et les gardes de page savaient ce que le rôle avait le droit de faire, et les deux ne se parlaient jamais : un utilisateur finance avait un onglet Market cliquable qui finissait en 404 tout nu. Une matrice, trois lecteurs. Fini les onglets vers nulle part.

Caché, pas 404

Un module que votre rôle ne peut pas ouvrir n’est simplement pas dans la navigation. Un utilisateur finance ne voit pas Market, Auction ni Sourcing ; un utilisateur commercial ne voit pas Escrow. Les pages de paramètres des modules que le tenant n’a pas disparaissent aussi du menu, au lieu de rebondir vers la page d’abonnement. Celui qui atterrit quand même sur une telle page via un favori, un lien d’e-mail ou un vieux raccourci reçoit une explication : de quel module il s’agit, que ce rôle ne peut pas l’ouvrir, quels rôles le peuvent, et un bouton de retour au dashboard. Les paramètres tenant réservés à l’administrateur de l’organisation — facturation, horaires d’ouverture, seuils d’analytics — restent visibles pour tout le monde mais s’ouvrent avec une mention « Géré par votre administrateur » pour les autres rôles. Une page qui s’explique coûte un paragraphe ; un 404 coûte un ticket de support.

Opérateur est le rôle par défaut

Opérateur est le rôle que porte une invitation tant que celui qui invite n’en choisit pas un autre, et c’est le rôle qui fait le travail de testing : l’écran de test est ouvert aux rôles administrateur, manager, entrepôt et opérateur. Les contrats vont dans l’autre sens — créer et modifier un contrat, ses services et ses taux, ses certifications exigées et l’accord signé est réservé à l’administrateur, au manager et au commercial, le même cercle qui peut en activer un. Entrepôt, opérateur, finance et lecteur lisent les contrats ; ils ne voient aucun bouton Modifier, Gérer ou Nouveau contrat, et un appel serveur direct est refusé et journalisé comme accès refusé.

Où se joue l’application des règles

La navigation de l’UI rend service, mais le serveur et la base de données sont les adultes de la pièce. Les gardes serveur lisent les rôles depuis les enregistrements de membership, pas depuis des métadonnées utilisateur modifiables. La RLS garde les données du tenant scopées au tenant. Le code admin en service role doit ajouter la portée tenant explicitement, parce que le service role contourne la RLS ; c’est du pouvoir avec de la paperasse, pas un raccourci.

Frontières d’Admin

Les pages Admin sont platform-only : les rôles plateforme voient les outils cross-tenant, et les utilisateurs non-plateforme sont redirigés hors d’Admin. Le profil tenant et l’administration d’équipe vivent dans Paramètres, sur /settings/organization-profile et /settings/users. Une route manquante est agaçante ; un outil cross-tenant qui fuit est un exercice d’évacuation.

Changements et audit

Les changements de rôle et de permission sont sensibles côté audit. La plateforme enregistre qui a changé les accès, ce qui a changé et pourquoi. Si un utilisateur voit soudain moins de boutons, le support doit pouvoir l’expliquer sans lire l’avenir dans le cache du navigateur.