Unități și echipe

Unitățile și echipele modelează apartenența imbricată într-o organization:


organization
└── unit
    └── team

Folosiți-le când un departament stabil sau un grup de lucru are nevoie de propriul share target sau domeniu administrativ. Groups sunt adesea mai simple pentru partajare ad hoc.

Roluri stocate

Domeniu	Roluri
Unit	`unit_admin`, `base_creator`, `base_approver`, `member`
Team	`team_lead`, `variant_creator`, `variant_deployer`, `variant_user`

unit_admin și team_lead au autoritate definită de gestionare a apartenenței în organization API. Etichetele creator/approver/deployer exprimă responsabilități workflow intenționate, dar prezența lor nu dovedește aplicarea la fiecare endpoint build sau deployment. Testați workflow-ul concret.

Reguli de apartenență

Un unit aparține unei singure organization.
Un team aparține unui singur unit.
Un user trebuie să fie membru al organization înainte de a se alătura unui unit sau team.
Un membru al team ar trebui să fie și în unit-ul părinte; rutele administrative aplică ierarhia la adăugarea membrilor.
Organization owners/admins și scoped administrators au puteri de administrare diferite, descrise în Roluri și domeniul permisiunilor.

Ghid de proiectare

Creați un unit doar dacă are o limită durabilă, de exemplu proprietate, responsabilitate de aprobare sau un domeniu distinct de partajare resources. Creați un team pentru un grup de lucru mai mic în acea limită.

Exemplu:


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

Nu codificați o schemă organizațională fără efect asupra autorizării. Imbricarea suplimentară crește riscul de apartenențe învechite și shares moștenite neașteptate.

Modificări sigure

Pentru adăugare, schimbare de rol sau eliminare:

înregistrați organization, unit, team, user și rolurile curente;
faceți o singură modificare;
testați o operație permisă;
testați o operație respinsă;
reîmprospătați sau reautentificați pentru a detecta comportamentul session învechite; și
revizuiți shares ale căror apartenențe țintă s-au schimbat.

Users pot aparține mai multor units și teams. Adăugarea unei apartenențe noi nu transferă și nu elimină una veche.

Limita ștergerii

Ștergerea unui unit sau team este o operație materială. Nu vă bazați pe afirmații generice precum “resources become unit-level” sau “unassigned resources are archived.” Înainte de ștergere, folosiți read-only inventory pentru a identifica apartenențe, shares, resources dependente, lucru activ și referințe externe. Exportați audit record-ul necesar și confirmați comportamentul cascade exact al versiunii implementate.

Dacă impactul nu este clar, eliminați mai întâi partajarea largă și membrii, păstrați obiectul și solicitați aprobarea owner înainte de ștergere.