Skip to Content
OrganizationsUnits e teams

Units e teams

Units e teams modelam membership aninhada dentro de uma organização:

organization
└── unit
    └── team

Use-os quando um departamento ou grupo de trabalho estável precisa de alvo de share ou escopo administrativo próprio. Groups costumam ser mais simples para sharing ad hoc.

Papéis armazenados

EscopoPapéis
Unitunit_admin, base_creator, base_approver, member
Teamteam_lead, variant_creator, variant_deployer, variant_user

unit_admin e team_lead têm autoridade definida de gerenciamento de membership na API de organização. Rótulos creator/approver/deployer expressam responsabilidades de workflow pretendidas, mas sua presença não prova enforcement por todo endpoint de build ou deployment. Teste o workflow específico.

Regras de membership

  • Uma unit pertence a uma organização.
  • Um team pertence a uma unit.
  • Usuário deve ser membro da organização antes de entrar em unit ou team.
  • Membro de team também deve estar na unit pai; rotas administrativas aplicam a hierarquia ao adicionar membros.
  • Owners/admins da organização e administradores no escopo têm poderes de gerenciamento diferentes, descritos em Papéis e escopo de permissão.

Orientação de design

Crie unit só se tiver limite durável como ownership, responsabilidade de aprovação ou escopo distinto de sharing de recursos. Crie team para grupo menor dentro desse limite.

Exemplo:

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

Não codifique organograma que não afeta autorização. Aninhamento extra aumenta chance de memberships stale e shares herdados inesperados.

Alterações seguras

Para add, mudança de papel ou remoção:

  1. registre organização, unit, team, usuário e papéis atuais;
  2. faça uma mudança;
  3. teste operação permitida;
  4. teste operação negada;
  5. refresh ou reautentique para detectar comportamento de sessão stale; e
  6. revise shares cujo membership alvo mudou.

Usuários podem pertencer a várias units e teams. Nova membership não transfere nem remove a antiga.

Limite de deleção

Deletar unit ou team é operação material. Não dependa de afirmações genéricas como “resources become unit-level” ou “unassigned resources are archived.” Antes da deleção, use inventário read-only para identificar memberships, shares, recursos dependentes, trabalho ativo e referências externas. Exporte registro de auditoria necessário e confirme comportamento de cascade exato da release implantada.

Se o impacto não estiver claro, remova sharing amplo e membros primeiro, preserve o objeto e busque aprovação do owner antes da deleção.

Compartilhando conversas e variantsReferência