Unit e team

Unit e team modellano membership annidata dentro un’organizzazione:

organization
└── unit
    └── team

Usali quando un reparto o gruppo di lavoro stabile ha bisogno del proprio target share o scope amministrativo. I gruppi sono spesso più semplici per condivisione ad hoc.

Ruoli memorizzati

unit_admin e team_lead hanno autorità gestione membership definita nell’API organizzazione. Le etichette creator/approver/deployer esprimono responsabilità workflow previste, ma la loro presenza non prova enforcement da ogni endpoint build o deploy. Testa il workflow specifico.

Regole membership

• Un’unit appartiene a una organizzazione.
• Un team appartiene a un’unit.
• Un utente deve essere membro organizzazione prima di unirsi a unit o team.
• Un membro team dovrebbe essere anche nell’unit genitore; le route amministrative applicano la gerarchia quando si aggiungono membri.
• Owner/admin organizzazione e amministratori con scope hanno poteri gestione diversi, descritti in Ruoli e ambito permessi.

Linee guida design

Crea un’unit solo se ha un confine durabile come ownership, responsabilità approvazione o scope condivisione risorse distinto. Crea un team per un gruppo di lavoro più piccolo dentro quel confine.

Esempio:

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

Non codificare un organigramma che non ha effetto sull’autorizzazione. Nesting extra aumenta il rischio di membership stale e share ereditate inattese.

Modifiche sicure

Per aggiunta, cambio ruolo o rimozione:

1. registra organizzazione, unit, team, utente e ruoli correnti;
2. fai un cambio;
3. testa un’operazione consentita;
4. testa un’operazione negata;
5. aggiorna o riautentica per rilevare comportamento sessione stale; e
6. rivedi share il cui target membership è cambiato.

Gli utenti possono appartenere a più unit e team. Aggiungere una nuova membership non trasferisce né rimuove una vecchia.

Confine eliminazione

Eliminare un’unit o team è un’operazione materiale. Non affidarti a affermazioni generiche come «le risorse diventano a livello unit» o «le risorse non assegnate sono archiviate». Prima dell’eliminazione, usa inventario read-only per identificare membership, share, risorse dipendenti, lavoro attivo e riferimenti esterni. Esporta il record audit richiesto e conferma il comportamento cascade esatto della release deployata.

Se l’impatto non è chiaro, rimuovi prima sharing ampio e membri, preserva l’oggetto e chiedi approvazione owner prima dell’eliminazione.