Rôles et périmètre des permissions

OpenFactory stocke des rôles indépendants aux niveaux organisation, unité et équipe. Un nom de rôle décrit un périmètre ; ce n’est pas une permission universelle qui s’applique automatiquement à chaque API ou fonctionnalité produit.

Modèle de périmètre


organization membership: owner | admin | member
└── unit membership: unit_admin | base_creator | base_approver | member
    └── team membership: team_lead | variant_creator | variant_deployer | variant_user

L’adhésion organisation est la frontière externe. Un utilisateur doit être membre de l’organisation avant qu’un administrateur ne l’ajoute à l’une de ses unités ou équipes. L’adhésion est vérifiée indépendamment à chaque niveau ; n’inférez pas un rôle unité ou équipe depuis un rôle organisation affiché dans un autre contexte.

Rôles organisation

L’API de gestion d’organisation actuelle applique ces permissions :

Opération	Owner	Admin	Member
Voir organisation, membres, groupes, unités et équipes	Oui	Oui	Oui
Modifier nom ou description de l’organisation	Oui	Oui	Non
Créer, modifier ou supprimer des groupes et gérer leurs membres	Oui	Oui	Non
Inviter ou retirer des membres ordinaires	Oui	Oui	Non
Changer les rôles member/admin ordinaires	Oui	Oui	Non
Inviter ou promouvoir un owner	Oui	Non	Non
Changer ou retirer un owner existant	Oui	Non	Non
Créer ou supprimer des unités	Oui	Oui	Non
Supprimer l’organisation	Oui	Non	Non
Quitter l’organisation	Oui, sauf seul owner	Oui	Oui

Une organisation peut avoir plusieurs owners. L’API empêche le seul owner de partir tant qu’un autre owner existe ou que l’organisation n’est pas supprimée. Il n’y a pas d’action séparée « transfer ownership » dans cette API ; un owner change le rôle d’un autre membre en owner, puis peut changer ou retirer l’owner précédent comme prévu.

Rôles unité

Les owners et admins organisation peuvent gérer chaque unité. Dans une unité, l’API de gestion d’organisation actuelle accorde à unit_admin les opérations administratives suivantes :

modifier l’unité ;
ajouter, retirer et changer les rôles des membres d’unité ;
créer, modifier et supprimer des équipes dans cette unité ;
ajouter et gérer les membres d’équipe dans cette unité.

Seul un owner ou admin organisation peut supprimer l’unité elle-même.

base_creator, base_approver et member d’unité sont des libellés de rôle stockés pour la politique de workflow d’images de base. Les routes CRUD organisation ne prouvent pas à elles seules que chaque action create, approve ou deploy ailleurs applique ces libellés. Vérifiez le comportement d’autorisation du workflow de build ou d’approbation spécifique avant de vous y fier comme contrôle.

Rôles équipe

Les owners/admins organisation et le unit_admin de l’unité parente peuvent gérer l’adhésion équipe. Un team_lead peut :

modifier le nom ou la description de l’équipe ;
ajouter et retirer des membres d’équipe ;
changer les rôles des membres d’équipe.

Un team_lead ne peut pas supprimer l’équipe via l’API organisation actuelle ; cette opération est réservée à un owner/admin organisation ou au unit_admin parent.

variant_creator, variant_deployer et variant_user expriment les responsabilités prévues du workflow variant. Ils ne doivent pas être lus comme preuve que chaque endpoint variant applique une matrice create/edit/deploy complète. Testez le workflow exact et les chemins refusés dans la version déployée.

Les groupes diffèrent

Les groupes sont des collections de partage au niveau organisation, pas une autre hiérarchie de rôles. Owners et admins créent des groupes et gèrent l’adhésion ; tous les membres organisation peuvent lister groupes et membres. Une adhésion à un groupe ne transforme pas un utilisateur en admin organisation, admin unité ou team lead.

Changer un rôle en sécurité

Confirmez l’organisation, unité ou équipe cible.
Enregistrez les adhésions effectives actuelles de l’utilisateur aux trois périmètres.
Appliquez un changement de rôle.
Testez une opération autorisée et une refusée avec la session de cet utilisateur.
Vérifiez que l’état UI en cache et les sessions existantes reflètent le changement.
Conservez un enregistrement d’audit en dehors du libellé de rôle si votre politique l’exige.

Changer un libellé sans test de chemin refusé n’est pas une preuve suffisante que le moindre privilège est appliqué.

Cas limites courants

Un admin ne peut promouvoir personne en owner ni changer le rôle d’un owner existant.
Un utilisateur ne peut être ajouté à une unité ou équipe qu’après appartenance à l’organisation.
Les membres unité et équipe peuvent se retirer eux-mêmes ; l’adhésion organisation reste sauf retrait séparé.
Le retrait d’adhésion organisation doit être vérifié pour effets obsolètes sur unité, équipe, groupe, partage et session dans votre version.
Les couleurs de badge UI sont de la présentation, pas un contrôle de sécurité. Appuyez-vous toujours sur l’autorisation côté serveur et les tests de chemins refusés.