Units och teams

Units och teams modellerar nästlade medlemskap i en organization:


organization
└── unit
    └── team

Använd dem när en stabil avdelning eller arbetsgrupp behöver ett eget share-mål eller administrativt scope. Groups är ofta enklare för ad hoc-delning.

Lagrade roller

Scope	Roller
Unit	`unit_admin`, `base_creator`, `base_approver`, `member`
Team	`team_lead`, `variant_creator`, `variant_deployer`, `variant_user`

unit_admin och team_lead har definierad behörighet för medlemskapshantering i organization API. Creator-/approver-/deployer-etiketterna uttrycker avsedda workflow-ansvar, men deras närvaro bevisar inte att varje build- eller deployment-endpoint tillämpar dem. Testa det specifika workflowet.

Medlemskapsregler

En unit tillhör en organization.
Ett team tillhör en unit.
En user måste vara organization-medlem innan hen går med i unit eller team.
En teammedlem bör också finnas i den överordnade unit; administrativa routes upprätthåller hierarkin när medlemmar läggs till.
Organization owners/admins och scoped administrators har olika hanteringsbefogenheter, beskrivna i Roller och behörighetsomfattning.

Designvägledning

Skapa en unit bara om den har en bestående gräns, till exempel ägarskap, godkännandeansvar eller ett särskilt resource-sharing-scope. Skapa ett team för en mindre arbetsgrupp inom den gränsen.

Exempel:


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

Koda inte in ett organisationsschema som inte påverkar auktorisering. Extra nästling ökar risken för inaktuella medlemskap och oväntade ärvda shares.

Säkra ändringar

Vid tillägg, rolländring eller borttagning:

anteckna organization, unit, team, user och nuvarande roller;
gör en ändring;
testa en tillåten operation;
testa en nekad operation;
uppdatera eller autentisera om för att upptäcka inaktuellt sessionsbeteende; och
granska shares vars målmedlemskap ändrats.

Users kan tillhöra flera units och teams. Ett nytt medlemskap flyttar eller tar inte bort ett gammalt.

Borttagningsgräns

Att ta bort en unit eller team är en väsentlig operation. Lita inte på generella påståenden som “resources become unit-level” eller “unassigned resources are archived.” Innan borttagning, använd read-only inventory för att identifiera medlemskap, shares, beroende resources, aktivt arbete och externa referenser. Exportera nödvändigt audit record och bekräfta exakt cascade-beteende i den utrullade releasen.

Om effekten är oklar, ta bort bred sharing och medlemmar först, behåll objektet och inhämta owner-godkännande före borttagning.