Organisationer
OpenFactorys organization API lagrar organisationsmedlemskap plus valfria groups, units och teams. Den tillhandahåller också mål för delning av conversations/variants.
organization
├── members: owner | admin | member
├── groups: organization-level sharing collections
└── units
├── unit members
└── teams
└── team membersDen här hierarkin är input till auktorisering. En rolletikett visar inte att varje build-, VM-, download- eller deployment-endpoint tillämpar avsedd policy. Se Roller och behörighetsomfång för de routes som för närvarande styrs av varje roll.
Kärnobjekt
- Organization: gräns för medlemskap och administration på översta nivån. En användare kan tillhöra flera organizations.
- Group: namngiven samling organization-medlemmar som används som share-mål; inte en administrativ hierarki.
- Unit: behållare i stil med avdelning, med eget medlemskap och lagrade workflow-roller.
- Team: underordnad unit med eget medlemskap och lagrade workflow-roller.
Användare måste vara organization-medlemmar innan de läggs till längre ner i strukturen.
Säker uppsättningsordning
- Skapa organization; skaparen blir owner.
- Lägg till en andra ansvarig owner innan du förlitar dig på organization för bestående operationer.
- Bjud in användare till deras exakta e-postadresser och tilldela lägsta nödvändiga organization-roll.
- Lägg till units eller teams endast när deras omfattning ändrar ett faktiskt workflow.
- Testa en tillåten och en nekad åtgärd med varje representativ roll.
- Granska share- och medlemskapets beteende efter borttagen roll och sessionsuppdatering.
Inbjudningar går ut och måste accepteras av ett konto vars e-post matchar inbjudan. Skicka inte invite tokens i ärenden eller offentliga loggar.
Kontext och ägande
Val av organization kan påverka synliga samarbetsdata, men enskilda resources har fortfarande regler för owner och share. Dra inte slutsatsen om åtkomst till privat build eller artifact bara för att två användare tillhör samma organization. Använd explicit delning där det stöds och testa download-/VM-åtgärden separat.
Isolationsbevis
Organization- och sharing-routes gör membership checks och same-organization validation för sina avgränsade operationer. “Tenant isolation” är en bredare systemegenskap och kräver cross-tenant denied-path-tester över conversations, builds, artifacts, VMs, API:er, caches, exports och logs. Använd inte organization-hierarkin ensam som det beviset.
Skydd vid administration
- Flera owners stöds; den enda owner kan inte lämna.
- Endast en owner kan befordra en annan owner eller ta bort organization.
- Borttagning och borttaget medlemskap kan påverka beroende åtkomst. Inventera shares, units, teams, aktiva sessioner och owned resources först.
- Behåll extern audit-post om er policy kräver det; en aktuell rollista är inte ett historiskt audit trail.
Fortsätt med Sharing och Units and Teams.