Units i teams

Units i teams modelują zagnieżdżone członkostwo w organization:


organization
└── unit
    └── team

Używaj ich, gdy stabilny dział lub grupa robocza potrzebuje własnego celu share lub zakresu administracyjnego. Groups są często prostsze przy ad hoc sharing.

Zapisane role

Zakres	Role
Unit	`unit_admin`, `base_creator`, `base_approver`, `member`
Team	`team_lead`, `variant_creator`, `variant_deployer`, `variant_user`

unit_admin i team_lead mają zdefiniowane uprawnienia do zarządzania członkostwem w organization API. Etykiety creator/approver/deployer opisują zamierzone obowiązki w workflow, ale sama ich obecność nie dowodzi egzekwowania przez każdy endpoint build lub deployment. Przetestuj konkretny workflow.

Reguły członkostwa

Unit należy do jednej organization.
Team należy do jednego unit.
User musi być członkiem organization, zanim dołączy do unit lub team.
Członek team powinien też należeć do nadrzędnego unit; trasy administracyjne wymuszają hierarchię przy dodawaniu członków.
Organization owners/admins i scoped administrators mają różne uprawnienia zarządzania, opisane w Role i zakres uprawnień.

Wskazówki projektowe

Twórz unit tylko wtedy, gdy ma trwałą granicę, na przykład własność, odpowiedzialność za zatwierdzenie lub odrębny zakres resource sharing. Twórz team dla mniejszej grupy roboczej w tej granicy.

Przykład:


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

Nie koduj schematu organizacyjnego, który nie wpływa na autoryzację. Dodatkowe zagnieżdżenie zwiększa ryzyko nieaktualnych członkostw i nieoczekiwanych odziedziczonych shares.

Bezpieczne zmiany

Przy dodaniu, zmianie roli lub usunięciu:

zapisz organization, unit, team, user i bieżące role;
wprowadź jedną zmianę;
przetestuj dozwoloną operację;
przetestuj odrzuconą operację;
odśwież lub uwierzytelnij ponownie, aby wykryć nieaktualne zachowanie sesji; oraz
przejrzyj shares, których docelowe członkostwo się zmieniło.

Users mogą należeć do wielu units i teams. Dodanie nowego członkostwa nie przenosi ani nie usuwa starego.

Granica usuwania

Usunięcie unit lub team to istotna operacja. Nie polegaj na ogólnych stwierdzeniach typu “resources become unit-level” lub “unassigned resources are archived.” Przed usunięciem użyj read-only inventory, aby zidentyfikować członkostwa, shares, zależne resources, aktywną pracę i zewnętrzne referencje. Wyeksportuj wymagany audit record i potwierdź dokładne cascade behavior wdrożonej wersji.

Jeśli wpływ nie jest jasny, najpierw usuń szerokie sharing i członków, zachowaj obiekt i uzyskaj zgodę owner przed usunięciem.