Unitit ja tiimit

Unitit ja tiimit mallintavat sisäkkäisen jäsenyyden organizationissa:


organization
└── unit
    └── team

Käytä niitä, kun vakiintunut osasto tai työryhmä tarvitsee oman share-kohteen tai hallinnollisen scope:n. Groups ovat usein yksinkertaisempia ad hoc -jakamiseen.

Tallennetut roolit

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

unit_admin- ja team_lead-rooleilla on määritelty jäsenyyden hallintavalta organization API:ssa. Creator-/approver-/deployer-tunnisteet kuvaavat tarkoitettuja workflow-vastuita, mutta niiden olemassaolo ei todista, että jokainen build- tai deployment-endpoint pakottaa ne. Testaa kyseinen workflow.

Jäsenyyssäännöt

Yksi unit kuuluu yhteen organizationiin.
Yksi team kuuluu yhteen unitiin.
Userin on oltava organization-jäsen ennen liittymistä unitiin tai teamiin.
Team-jäsenen pitäisi olla myös ylätason unitissa; hallintareitit pakottavat hierarkian jäseniä lisättäessä.
Organization owners/admins ja scoped administrators -rooleilla on eri hallintavalta, kuvattu kohdassa Roolit ja käyttöoikeusalue.

Suunnitteluohje

Luo unit vain, jos sillä on pysyvä raja, kuten omistajuus, hyväksyntävastuu tai erillinen resource-sharing-scope. Luo team pienemmälle työryhmälle tuon rajan sisällä.

Esimerkki:


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

Älä koodaa organisaatiokaaviota, jolla ei ole vaikutusta valtuutukseen. Ylimääräinen sisäkkäisyys lisää riskiä vanhentuneista jäsenyyksistä ja odottamattomista perityistä shareista.

Turvalliset muutokset

Lisäyksessä, roolimuutoksessa tai poistossa:

kirjaa organization, unit, team, user ja nykyiset roolit;
tee yksi muutos;
testaa sallittu operaatio;
testaa evätty operaatio;
päivitä tai tunnistaudu uudelleen vanhentuneen istuntokäyttäytymisen havaitsemiseksi; ja
tarkista sharet, joiden kohdejäsenyys muuttui.

Users voivat kuulua useisiin uniteihin ja teameihin. Uuden jäsenyyden lisääminen ei siirrä eikä poista vanhaa.

Poistoraja

Unitin tai teamin poistaminen on merkittävä operaatio. Älä luota yleisiin väittämiin kuten “resources become unit-level” tai “unassigned resources are archived.” Ennen poistoa käytä read-only inventorya tunnistaaksesi jäsenyydet, sharet, riippuvat resources, aktiivisen työn ja ulkoiset viitteet. Vie vaadittu audit record ja varmista käyttöönotetun releasen tarkka cascade-käyttäytyminen.

Jos vaikutus on epäselvä, poista ensin laaja sharing ja jäsenet, säilytä objekti ja hanki owner-hyväksyntä ennen poistoa.