Unités et équipes

Les unités et équipes modélisent une adhésion imbriquée dans une organisation :


organization
└── unit
    └── team

Utilisez-les lorsqu’un département ou groupe de travail stable a besoin de sa propre cible de partage ou périmètre administratif. Les groupes sont souvent plus simples pour le partage ad hoc.

Rôles stockés

Périmètre	Rôles
Unit	`unit_admin`, `base_creator`, `base_approver`, `member`
Team	`team_lead`, `variant_creator`, `variant_deployer`, `variant_user`

unit_admin et team_lead ont une autorité de gestion d’adhésion définie dans l’API organisation. Les libellés creator/approver/deployer expriment des responsabilités de workflow prévues, mais leur présence ne prouve pas l’application par chaque endpoint build ou deploy. Testez le workflow spécifique.

Règles d’adhésion

Une unité appartient à une organisation.
Une équipe appartient à une unité.
Un utilisateur doit être membre organisation avant de rejoindre une unité ou équipe.
Un membre d’équipe devrait aussi être dans l’unité parente ; les routes administratives appliquent la hiérarchie à l’ajout de membres.
Owners/admins organisation et administrateurs limités ont des pouvoirs de gestion différents, décrits dans Rôles et périmètre des permissions.

Conseils de conception

Créez une unité seulement si elle a une frontière durable comme propriété, responsabilité d’approbation ou périmètre de partage de ressources distinct. Créez une équipe pour un groupe de travail plus petit dans cette frontière.

Exemple :


Acme
├── Platform unit
│   ├── Image engineering team
│   └── Security review team
└── Product unit
    └── Device application team

N’encodez pas un organigramme sans effet sur l’autorisation. L’imbrication supplémentaire augmente le risque d’adhésions obsolètes et de partages hérités inattendus.

Changements sûrs

Pour un ajout, changement de rôle ou retrait :

enregistrez organisation, unité, équipe, utilisateur et rôles courants ;
effectuez un changement ;
testez une opération autorisée ;
testez une opération refusée ;
rafraîchissez ou réauthentifiez pour détecter un comportement de session obsolète ; et
relisez les partages dont l’adhésion cible a changé.

Les utilisateurs peuvent appartenir à plusieurs unités et équipes. Ajouter une adhésion ne transfère ni ne retire une ancienne.

Frontière de suppression

Supprimer une unité ou équipe est une opération matérielle. Ne vous fiez pas à des affirmations génériques du type « resources become unit-level » ou « unassigned resources are archived ». Avant suppression, utilisez un inventaire en lecture seule pour identifier adhésions, partages, ressources dépendantes, travail actif et références externes. Exportez l’enregistrement d’audit requis et confirmez le comportement de cascade exact de la version déployée.

Si l’impact n’est pas clair, retirez d’abord partages larges et membres, conservez l’objet et demandez l’approbation du owner avant suppression.