Units og teams

Units og teams modellerer nested medlemskap i en organization:


organization
└── unit
    └── team

Bruk dem når en stabil avdeling eller arbeidsgruppe trenger sitt eget share-mål eller administrative scope. Groups er ofte enklere for ad hoc-deling.

Lagrede roller

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

unit_admin og team_lead har definert myndighet for medlemskapshåndtering i organization API. Creator-/approver-/deployer-etiketter uttrykker tiltenkte workflow-ansvar, men deres tilstedeværelse beviser ikke håndhevelse av hvert build- eller deployment-endpoint. Test den konkrete workflowen.

Medlemskapsregler

En unit tilhører én organization.
Et team tilhører én unit.
En user må være organization-medlem før vedkommende slutter seg til unit eller team.
Et teammedlem bør også være i den overordnede unit; administrative routes håndhever hierarkiet når medlemmer legges til.
Organization owners/admins og scoped administrators har ulike styringsbeføyelser, beskrevet i Roller og tillatelsesomfang.

Designveiledning

Opprett en unit bare hvis den har en varig grense, for eksempel eierskap, godkjenningsansvar eller et særskilt resource-sharing-scope. Opprett et team for en mindre arbeidsgruppe innenfor den grensen.

Eksempel:


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

Ikke kod inn et organisasjonsskjema uten effekt på autorisasjon. Ekstra nesting øker sjansen for utdaterte medlemskap og uventede arvede shares.

Trygge endringer

Ved tillegg, rolleendring eller fjerning:

noter organization, unit, team, user og nåværende roller;
gjør én endring;
test en tillatt operasjon;
test en avvist operasjon;
oppdater eller autentiser på nytt for å oppdage utdatert sesjonsatferd; og
gå gjennom shares der målmedlemskapet er endret.

Users kan tilhøre flere units og teams. Et nytt medlemskap overfører eller fjerner ikke et gammelt.

Slettegrense

Sletting av en unit eller team er en vesentlig operasjon. Stol ikke på generelle utsagn som “resources become unit-level” eller “unassigned resources are archived.” Før sletting, bruk read-only inventory for å identifisere medlemskap, shares, avhengige resources, aktivt arbeid og eksterne referanser. Eksporter påkrevd audit record, og bekreft nøyaktig cascade-atferd i den utrullede releasen.

Hvis effekten er uklar, fjern bred sharing og medlemmer først, behold objektet, og innhent owner-godkjenning før sletting.