Units un teams

Units un teams modelē ligzdošo dalību organization:

organization
└── unit
    └── team

Izmantojiet tos, ja stabilam departamentam vai darba grupai vajag savu share mērķi vai administratīvo scope. Groups bieži ir vienkāršāki ad hoc koplietošanai.

Saglabātās lomas

unit_admin un team_lead organization API ir definēta dalības pārvaldības pilnvara. Creator/approver/deployer etiķetes izsaka paredzētās workflow atbildības, taču to klātbūtne nedod pierādījumu, ka katrs build vai deployment endpoint to piemēro. Pārbaudiet konkrēto workflow.

Dalības noteikumi

• Viena unit pieder vienai organization.
• Vienam team pieder viena unit.
• Lietotājam jābūt organization dalībniekam, pirms pievienojas unit vai team.
• Team dalībniekam vajadzētu būt arī vecākunit; administratīvie maršruti pie dalībnieku pievienošanas ievēro hierarhiju.
• Organization owners/admins un scoped administrators ir atšķirīgas pārvaldības pilnvaras, aprakstītas Lomas un atļaujas.

Projektēšanas ieteikumi

Izveidojiet unit tikai tad, ja tai ir ilgstoša robeža, piemēram, īpašumtiesības, apstiprinājuma atbildība vai atsevišķs resource-sharing scope. Izveidojiet team mazākai darba grupai šajā robežā.

Piemērs:

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

Nekodējiet organizācijas shēmu, kurai nav ietekmes uz autorizāciju. Papildu ligzdošana palielina novecojušu dalību un negaidītu mantoto shares risku.

Droši labojumi

Pievienojot, mainot lomu vai noņemot:

1. fiksējiet organization, unit, team, user un pašreizējās lomas;
2. veiciet vienu izmaiņu;
3. pārbaudiet atļautu operāciju;
4. pārbaudiet noraidītu operāciju;
5. atjaunojiet vai atkārtoti autentificējieties, lai pamanītu novecojušas sesijas uzvedību; un
6. pārskatiet shares, kuru mērķa dalība mainījās.

Lietotāji var piederēt vairākām units un teams. Jaunas dalības pievienošana nepārvieto un noņem veco.

Dzēšanas robeža

Unit vai team dzēšana ir būtiska operācija. Neuzskatieties uz vispārīgiem apgalvojumiem, piemēram, “resources become unit-level” vai “unassigned resources are archived.” Pirms dzēšanas izmantojiet read-only inventory, lai identificētu dalības, shares, atkarīgos resources, aktīvo darbu un ārējās atsauces. Eksportējiet nepieciešamo audit record un apstipriniet izlaistās versijas precīzu cascade uzvedību.

Ja ietekme nav skaidra, vispirms noņemiet plašu koplietošanu un dalībniekus, saglabājiet objektu un saņemiet owner apstiprinājumu pirms dzēšanas.