Organisations

L’API organisation OpenFactory stocke les adhésions organisation plus groupes, unités et équipes optionnels. Elle fournit aussi des cibles pour le partage de conversations/variants.

organization
├── members: owner | admin | member
├── groups: organization-level sharing collections
└── units
    ├── unit members
    └── teams
        └── team members

Cette hiérarchie est une entrée d’autorisation. Un libellé de rôle ne prouve pas que chaque build, VM, téléchargement ou point de déploiement applique la politique voulue. Voir Rôles et périmètre des permissions pour les routes actuellement gouvernées par chaque rôle.

Objets principaux

• Organization : frontière d’adhésion et d’administration de premier niveau. Un utilisateur peut appartenir à plusieurs organisations.
• Group : collection nommée de membres d’organisation utilisée comme cible de partage ; ce n’est pas une hiérarchie administrative.
• Unit : conteneur type département avec sa propre adhésion et rôles de workflow stockés.
• Team : enfant d’une unité avec sa propre adhésion et rôles de workflow stockés.

Les utilisateurs doivent être membres de l’organisation avant d’être ajoutés en dessous.

Séquence de configuration sûre

1. Créez l’organisation ; le créateur devient owner.
2. Ajoutez un second owner responsable avant de compter sur l’organisation pour des opérations durables.
3. Invitez les utilisateurs à leurs adresses e-mail exactes et assignez le rôle organisation le plus bas requis.
4. Ajoutez unités ou équipes seulement lorsque leur périmètre change un workflow réel.
5. Testez une action autorisée et une refusée avec chaque rôle représentatif.
6. Relisez le comportement de partage et d’adhésion après retrait de rôle et rafraîchissement de session.

Les invitations expirent et doivent être acceptées par un compte dont l’e-mail correspond à l’invitation. Ne transmettez pas de jetons d’invitation dans des tickets ou journaux publics.

Contexte et propriété

La sélection d’organisation peut affecter les données de collaboration visibles, mais chaque ressource porte encore des règles de propriétaire et de partage. N’inférez pas l’accès à un build ou artefact privé parce que deux utilisateurs appartiennent à la même organisation. Utilisez un partage explicite lorsque supporté et testez l’action téléchargement/VM séparément.

Preuve d’isolation

Les routes organisation et partage effectuent des vérifications d’adhésion et une validation même-organisation pour leurs opérations limitées. « Tenant isolation » est une propriété système plus large et nécessite des tests de chemins refusés inter-locataires sur conversations, builds, artefacts, VM, API, caches, exports et journaux. N’utilisez pas la hiérarchie organisation seule comme cette preuve.

Garde-fous d’administration

• Plusieurs owners sont supportés ; le seul owner ne peut pas partir.
• Seul un owner peut promouvoir un autre owner ou supprimer l’organisation.
• Suppression et retrait d’adhésion peuvent affecter l’accès dépendant. Inventoriez d’abord partages, unités, équipes, sessions actives et ressources possédées.
• Conservez un enregistrement d’audit externe si votre politique l’exige ; une liste de rôles courante n’est pas une piste d’audit historique.

Poursuivez avec Partage et Unités et équipes.