Permissões e Funções

O Canopy utiliza um modelo de permissões de três camadas que combina controlo de acesso baseado em funções a nível de toda a aplicação com funções de partes interessadas específicas de cada cartão. Esta página explica o design, quando usar cada camada e como as camadas se combinam em permissões efetivas.

Porquê três camadas?

A Arquitetura Empresarial é inerentemente transversal a funções. Um determinado cartão — por exemplo, uma Application — pode ser:

• Apenas de leitura para a maioria dos utilizadores (os espectadores veem o inventário mas não podem editar)
• Editável pela equipa de AE geral (os membros podem atualizar qualquer cartão)
• Gerido por uma pessoa específica responsável por essa aplicação (o Responsável Técnico da Aplicação pode editar e aprovar o estado, mesmo que não tenha direitos de edição a nível organizacional)
• Totalmente controlado pelos administradores (que podem fazer tudo)

Um sistema de funções plano resolve os três primeiros casos mas falha no quarto: ou se concedem a alguém direitos de edição a nível organizacional (demasiado amplos) ou nada (demasiado restritivo). A camada de partes interessadas resolve isto ao conceder permissões por cartão a indivíduos específicos.

Camada 1 — Funções da aplicação

As funções da aplicação são atribuídas a utilizadores e aplicam-se em toda a plataforma. São definidas e geridas em Administração → Utilizadores e Funções.

Cada função possui um conjunto de permissões em JSON. As funções integradas são:

Função	Chave	Âmbito
Admin	admin	Wildcard {"*": true} — sem restrições
Admin BPM	bpm_admin	BPM completo + inventário completo, sem admin.*
Membro	member	Inventário completo + edição BPM, sem admin.*
Espectador	viewer	Apenas visualização em todos os domínios

As funções personalizadas podem ser criadas com qualquer combinação das chaves de permissão disponíveis, agrupadas em domínios como inventory.*, reports.*, bpm.*, ppm.*, grc.*, todos.*, admin.*.

Utilize funções da aplicação quando precisa de controlar o que uma classe de utilizadores pode fazer em toda a plataforma.

Camada 2 — Funções de partes interessadas

As funções de partes interessadas são atribuídas a utilizadores em cartões específicos. Cada tipo de cartão define o seu próprio conjunto de definições de funções de partes interessadas (por exemplo, os cartões Application têm "Responsável Técnico da Aplicação", "Responsável de Negócio da Aplicação", "Gestor de Dados"). Estas são configuradas em Administração → Metamodelo → [tipo] → Funções de Partes Interessadas.

Cada definição de função de partes interessadas possui um conjunto de permissões ao nível do cartão — como card.edit, card.approve, card.manage_relations. Quando um utilizador é adicionado como parte interessada num cartão, obtém essas permissões apenas nesse cartão.

Utilize funções de partes interessadas quando a propriedade ou responsabilidade é específica de um cartão: o responsável por uma aplicação específica deve poder geri-la sem obter direitos de edição nas restantes 500 aplicações.

Camada 3 — Permissões efetivas

Quando um utilizador tenta realizar uma ação num cartão, o sistema calcula as suas permissões efetivas combinando:

1. As permissões da sua função na aplicação (mapeadas de chaves ao nível da plataforma para chaves ao nível do cartão)
2. Todas as permissões de funções de partes interessadas que detém nesse cartão específico

O resultado é a união de ambos os conjuntos. Um utilizador que é Espectador (a nível de toda a plataforma) mas Responsável Técnico da Aplicação num cartão pode editar esse cartão, porque a função de parte interessada concede card.edit mesmo que a função de Espectador não o faça.

As permissões efetivas do utilizador atual num determinado cartão estão disponíveis em GET /cards/{id}/effective-permissions e controlam todos os controlos de edição/aprovação/eliminação na interface.

O wildcard de administrador

A função Admin utiliza {"*": true} como conjunto de permissões. Isto é avaliado como "permitir tudo" — incluindo permissões que não existiam quando a função foi criada. Isto significa que novos módulos e novas chaves de permissão ficam automaticamente disponíveis para os administradores sem qualquer atualização de função.

Nenhuma outra função integrada utiliza o wildcard. Ao criar funções personalizadas, utilize chaves de permissão explícitas em vez de wildcards — isso torna o âmbito da função auditável e evita a concessão acidental de permissões excessivas.

Estrutura das chaves de permissão

Todas as chaves de permissão seguem o padrão domínio.ação:

• inventory.view — ler cartões
• inventory.edit — atualizar cartões
• inventory.create — criar cartões
• admin.metamodel — gerir tipos de cartão e tipos de relação
• admin.impersonate — agir temporariamente como uma função diferente (ver Personificação de Função)
• bpm.approve — aprovar versões de fluxo de processo BPMN
• todos.view / todos.create / todos.manage — aceder e gerir tarefas pendentes
• risks.manage — criar e atualizar entradas no registo de riscos

A lista completa de chaves válidas está em backend/app/core/permissions.py, que é a fonte única de verdade. As novas chaves de permissão devem ser adicionadas aí antes de poderem ser concedidas a qualquer função.

Padrões comuns

Restringir um módulo a uma equipa: Crie uma função personalizada apenas com as permissões ppm.* e inventory.view. Atribua-a à equipa de portefólio de projetos. Eles podem trabalhar em PPM mas não podem editar o inventário principal.

Conceder direitos de aprovação sem direitos de edição: Dê a uma parte interessada de negócio a função de partes interessadas "Responsável de Negócio da Aplicação" em cartões Application específicos. Configure essa função para incluir card.approval_status mas não card.edit. Eles podem aprovar cartões que a equipa de AE preencheu, mas não podem alterar os dados.

Acesso de emergência para um administrador: O wildcard de administrador significa que qualquer permissão futura — incluindo permissões adicionadas por extensões ou versões futuras — é automaticamente concedida. Utilize a função Admin apenas para utilizadores que realmente precisam de acesso irrestrito.

Testar como uma função específica: Os utilizadores com admin.impersonate podem mudar para qualquer função não-administradora a partir do menu de utilizador (Ver como função…) para verificar exatamente o que essa função pode ver e fazer — sem criar uma conta de teste separada. A sessão de personificação é apenas de JWT e não deixa qualquer rasto na conta subjacente. Consulte Personificação de Função para o fluxo de trabalho completo.

Consulte também

• Utilizadores e Funções — criar e editar funções da aplicação
• Administração do metamodelo — configurar funções de partes interessadas por tipo de cartão
• Detalhe do Cartão: separador Partes Interessadas — atribuir partes interessadas a um cartão