Units og teams

Units og teams modellerer indlejret medlemskab i en organization:


organization
└── unit
    └── team

Brug dem, når en stabil afdeling eller arbejdsgruppe har brug for sit eget share-mål eller administrative scope. Groups er ofte enklere til 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 defineret myndighed til medlemskabshåndtering i organization API. Creator-/approver-/deployer-etiketter udtrykker tilsigtede workflow-ansvar, men deres tilstedeværelse beviser ikke håndhævelse af hvert build- eller deployment-endpoint. Test det konkrete workflow.

Medlemskabsregler

En unit hører til én organization.
Et team hører til én unit.
En user skal være organization-medlem, før vedkommende tilslutter sig unit eller team.
Et teammedlem bør også være i den overordnede unit; administrative routes håndhæver hierarkiet, når medlemmer tilføjes.
Organization owners/admins og scoped administrators har forskellige styringsbeføjelser, beskrevet i Roller og tilladelsesomfang.

Designvejledning

Opret kun en unit, hvis den har en varig grænse, for eksempel ejerskab, godkendelsesansvar eller et særskilt resource-sharing-scope. Opret et team til en mindre arbejdsgruppe inden for den grænse.

Eksempel:


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

Kod ikke et organisationsskema uden effekt på autorisation. Ekstra nesting øger risikoen for forældede medlemskaber og uventede arvede shares.

Sikre ændringer

Ved tilføjelse, rolleændring eller fjernelse:

notér organization, unit, team, user og nuværende roller;
foretag én ændring;
test en tilladt operation;
test en afvist operation;
opdater eller genautentificér for at opdage forældet sessionsadfærd; og
gennemgå shares, hvis målmedlemskab er ændret.

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

Sletningsgrænse

Sletning af en unit eller team er en væsentlig operation. Stol ikke på generelle udsagn som “resources become unit-level” eller “unassigned resources are archived.” Før sletning, brug read-only inventory til at identificere medlemskaber, shares, afhængige resources, aktivt arbejde og eksterne referencer. Eksportér det påkrævede audit record, og bekræft præcis cascade-adfærd i den udrullede release.

Hvis effekten er uklar, fjern bred sharing og medlemmer først, bevar objektet, og indhent owner-godkendelse før sletning.