Organizações

A API de organizações do OpenFactory armazena memberships de organização mais groups, units e teams opcionais. Também fornece alvos para compartilhar conversas/variants.

organization
├── members: owner | admin | member
├── groups: organization-level sharing collections
└── units
    ├── unit members
    └── teams
        └── team members

Esta hierarquia é entrada de autorização. Um rótulo de papel não prova que todo build, VM, download ou endpoint de deployment aplica a política pretendida. Veja Papéis e escopo de permissão para as rotas atualmente governadas por cada papel.

Objetos principais

• Organization: limite superior de membership e administração. Um usuário pode pertencer a várias organizações.
• Group: coleção nomeada de membros da organização usada como alvo de share; não é hierarquia administrativa.
• Unit: container tipo departamento com membership próprio e papéis de workflow armazenados.
• Team: filho de uma unit com membership próprio e papéis de workflow armazenados.

Usuários devem ser membros da organização antes de serem adicionados abaixo dela.

Sequência de setup segura

1. Crie a organização; o criador torna-se owner.
2. Adicione um segundo owner responsável antes de depender da organização para operações duráveis.
3. Convide usuários para os endereços de email exatos e atribua o papel de organização mais baixo necessário.
4. Adicione units ou teams só quando o escopo mudar um workflow real.
5. Teste uma ação permitida e uma negada usando cada papel representativo.
6. Revise comportamento de share e membership após remoção de papel e refresh de sessão.

Convites expiram e devem ser aceitos por conta cujo email corresponde ao convite. Não transmita tokens de convite em tickets ou logs públicos.

Contexto e propriedade

Seleção de organização pode afetar dados visíveis de colaboração, mas recursos individuais ainda carregam regras de owner e share. Não infira acesso a build ou artefato privado só porque dois usuários pertencem à mesma organização. Use share explícito onde suportado e teste a ação de download/VM separadamente.

Evidência de isolamento

As rotas de organização e sharing fazem checagens de membership e validação same-organization para suas operações no escopo. “Isolamento de tenant” é propriedade mais ampla do sistema e precisa de testes de caminho negado cross-tenant em conversas, builds, artefatos, VMs, APIs, caches, exports e logs. Não use só a hierarquia de organização como essa evidência.

Salvaguardas de administração

• Vários owners são suportados; o único owner não pode sair.
• Só um owner pode promover outro owner ou deletar a organização.
• Deleção e remoção de membership podem afetar acesso dependente. Inventarie shares, units, teams, sessões ativas e recursos owned primeiro.
• Preserve registro de auditoria externo se sua política exigir; listagem atual de papéis não é trilha histórica de auditoria.

Continue em Sharing e Units e teams.