Papéis e escopo de permissão

O OpenFactory armazena papéis independentes nos níveis de organização, unit e team. Um nome de papel descreve um escopo; não é permissão universal que se aplica automaticamente a toda API ou feature do produto.

Modelo de escopo

organization membership: owner | admin | member
└── unit membership: unit_admin | base_creator | base_approver | member
    └── team membership: team_lead | variant_creator | variant_deployer | variant_user

Membership na organização é o limite externo. Um usuário deve ser membro da organização antes de um administrador poder adicioná-lo a units ou teams dela. Membership é checada independentemente em cada nível; não infira papel de unit ou team a partir de papel de organização exibido em outro contexto.

Papéis de organização

A API atual de gerenciamento de organização aplica estas permissões:

Uma organização pode ter mais de um owner. A API impede que o único owner saia até existir outro owner ou a organização ser deletada. Não há ação separada de “transfer ownership” nesta API; um owner altera o papel de outro member para owner, depois pode alterar ou remover o owner anterior conforme pretendido.

Papéis de unit

Owners e admins da organização podem gerenciar toda unit. Dentro de uma unit, a API atual de gerenciamento de organização concede a unit_admin as seguintes operações administrativas:

• editar a unit;
• adicionar, remover e alterar papéis de membros da unit;
• criar, editar e deletar teams nessa unit;
• adicionar e gerenciar membros de team nessa unit.

Só owner ou admin da organização pode deletar a unit em si.

base_creator, base_approver e member de unit são rótulos de papel armazenados para política de workflow de imagem base. As rotas CRUD de organização por si não provam que toda ação de create, approve ou deployment em outro lugar aplica esses rótulos. Verifique o comportamento de autorização do workflow específico de build ou aprovação antes de confiar nele como controle.

Papéis de team

Owners/admins da organização e unit_admin da unit pai podem gerenciar membership de team. Um team_lead pode:

• editar nome ou descrição do team;
• adicionar e remover membros do team;
• alterar papéis de membros do team.

Um team_lead não pode deletar o team pela API de organização atual; essa operação fica reservada a owner/admin da organização ou unit_admin pai.

variant_creator, variant_deployer e variant_user expressam as responsabilidades pretendidas do workflow de variant. Não devem ser lidos como prova de que todo endpoint de variant aplica matriz completa create/edit/deploy. Teste o workflow exato e caminhos negados na release implantada.

Groups são diferentes

Groups são coleções de sharing no nível da organização, não outra hierarquia de papéis. Owners e admins criam groups e gerenciam membership de group; todos os membros da organização podem listar groups e seus membros. Membership em group não transforma usuário em admin de organização, admin de unit ou team lead.

Alterar um papel com segurança

1. Confirme a organização, unit ou team alvo.
2. Registre memberships efetivas atuais do usuário nos três escopos.
3. Aplique uma alteração de papel.
4. Teste operação permitida e negada com a sessão do próprio usuário.
5. Verifique se estado em cache da UI e sessões existentes refletem a mudança.
6. Retenha registro de auditoria fora do rótulo de papel se sua política exigir.

Alterar rótulo sem teste de caminho negado não é evidência suficiente de que menor privilégio está aplicado.

Casos limite comuns

• Admin não pode promover ninguém a owner nem alterar papel de owner existente.
• Usuário não pode ser adicionado a unit ou team até pertencer à organização.
• Membros de unit e team podem se remover; membership na organização permanece salvo remoção separada.
• Remover membership na organização deve ser checado quanto a efeitos stale em unit, team, group, share e sessão na sua release.
• Cores de badge na UI são apresentação, não controle de segurança. Confie sempre em autorização server-side e testes de caminho negado.