Permissões (RBAC/ABAC) — visão geral

O módulo de Permissões é onde uma pessoa com acesso de gestão cadastra papéis (roles), atribui um papel a um usuário — num grupo inteiro ou numa unidade específica — e, quando precisa de uma regra mais fina do que "tem ou não tem a permissão", cria uma política de negação ou confirmação (ABAC, controle por atributo). Ele é a interface do RBAC (controle de acesso por papéis) documentado no backend em Authorization — visão geral; esta página cobre a experiência de tela — o que cada rota realmente mostra, quem viu o quê nos testes, e onde a interface esconde mais do que a rota bloqueia.

Este levantamento cobre a interface (Angular) do repositório mm-pacs-portal-main-interface, branch integration/with-fixlaudo, testada no ambiente https://task4.srv1812538.hstgr.cloud/.

As três rotas e o componente que cada uma reaproveita

Existem três URLs para telas de RBAC, mas só dois componentes de tela distintos: a rota de grupo é literalmente a mesma tela de catálogo de papéis, apenas pré-filtrada por um grupo — não é uma tela separada.

• /admin/roles e /admin/tenant/:id/permissions renderizam o mesmo RoleComponent (confirmado no código: OrganizationPermissionsComponent só importa RoleComponent e repassa o id da rota como tenantId). A única diferença observável é qual grupo já vem selecionado no filtro "Grupo" ao abrir a tela — em /admin/roles, sem um grupo padrão (ver "Estado sem grupo selecionado" abaixo); na aba do detalhe do grupo, o próprio grupo já vem selecionado. Em ambos os casos, o filtro continua editável — nada impede trocar de grupo pelo combobox, mesmo dentro da aba "Permissões" de um grupo específico. Ver Papéis e políticas.
• /admin/company/:id/permissions é uma tela diferente e mais simples: não lista nem edita papéis, só mostra os membros efetivos da unidade e permite atribuir/revogar um papel por membro. Ver Permissões da unidade.

Confirmamos isso navegando com o administrador de plataforma: abrir /admin/tenant/:id/permissions mostra o mesmo cabeçalho "Permissões", as mesmas abas Papéis/Políticas e a mesma tabela de /admin/roles, com o grupo já pré-selecionado no filtro.

Modelo de permissões que a tela expõe

A tela reflete o mesmo modelo do backend (RBAC com papéis de sistema e customizados, mais uma camada ABAC de políticas por cima) — ver o detalhamento em Authorization — visão geral. O que vale destacar do lado da interface:

• O catálogo de permissões exibido no formulário de papel tem 78 permissões atribuíveis, agrupadas em 18 recursos (Exams, Reports, Users, Units, Access roles, Permissions, Authorization policies, Audit, Internal codes, User groups, Patients, Medical catalog, Report masks, SLA, Security, Accounts, Organizational groups, Profile files, Tenants), contados neste ambiente de teste. Os nomes dos recursos e das ações de cada permissão aparecem em inglês dentro de uma interface toda em português — uma inconsistência de tradução real, não um erro de captura.
• Um papel system (Administrador, Médico, Gerente, Técnico, Residente, Read only, Digitador, Solicitante, Financial) aparece com a etiqueta Reservado e não tem botão Editar — só Clonar e, para quem tem role:write, Atribuir a usuário no menu Mais ações. Um papel customizado (tenant_custom) tem Editar e, se não estiver em uso, poderia ser excluído pelo mesmo menu (não testamos a exclusão para não afetar os fixtures de outra linha de documentação).
• Uma política ABAC criada pela tela usa campos Recurso + Ação separados (ex.: user + export), não o par permission_name (user:export) que a API documenta — o front decompõe e recompõe esse par internamente (PolicyMapper). Do ponto de vista de quem preenche o formulário, isso não muda nada; é só uma diferença de modelagem entre a tela e a API que vale saber se você for depurar uma política pelo Swagger.

Quem acessa: o que este levantamento confirmou navegando

Testamos 4 dos 9 perfis de docs-usuarios.md (todos vinculados só à unidade "Unidade Central Docs", do grupo "Clínica Docs Portal 2" — nenhum tem uma atribuição separada no grupo): administrator, manager, read_only e financial. Os outros cinco perfis (doctor, technician, resident, typist, requestor) não foram testados navegando neste levantamento — A confirmar — responsável: time de frontend; data: 24/09/2026. Comparamos também com o administrador de plataforma (e2e.preparation.admin), usado como referência de "acesso irrestrito".

O que a pessoa tenta	administrator	manager	read_only	financial	Administrador de plataforma
Ver o item Permissões no menu lateral da Administração (/admin/roles)	Não aparece	Não testado	Não aparece	Não aparece	Aparece
Abrir /admin/roles por URL direta	Negado — redireciona para /admin/tenant	Não testado	Negado — mesmo redirecionamento	Negado — mesmo redirecionamento	Permitido
Abrir /admin/tenant/:id/permissions por URL direta	Negado — redireciona para /admin/tenant (a rota do grupo já bloqueia antes)	Não testado	Não testado	Não testado	Permitido
Ver o item Permissões no menu lateral da unidade	Não aparece	Não aparece	Não testado	Não testado	Aparece
Abrir /admin/company/:id/permissions por URL direta	Permitido — tela completa e funcional	Permitido — tela completa e funcional	Negado — redireciona para /admin/tenant	Negado — mesmo redirecionamento	Permitido
Formulário Atribuir papel na unidade habilitado	Sim	Sim	— (tela nem abre)	— (tela nem abre)	Sim
Botão Revogar (✕) em cada papel direto	Aparece	Aparece	—	—	Aparece

O padrão observado

1. O item de menu esconde mais do que a rota bloqueia — mas aqui a rota também bloqueia, só que de forma diferente por tela. Para o catálogo de papéis (/admin/roles, /admin/tenant/:id/permissions), a rota exige role:read no tenant — e nenhum dos quatro perfis testados tem qualquer permissão concedida no tenant (todos foram atribuídos só na unidade, pelo wizard de criação). Por isso os quatro são redirecionados silenciosamente para /admin/tenant, sem toast e sem página de erro — o mesmo padrão de redirecionamento silencioso já documentado em Administração e Auditoria.
2. Para a tela de permissões da unidade, a rota concede acesso mesmo sem o item de menu. administrator e manager — cujo papel de sistema inclui role:manage — abrem /admin/company/:id/permissions direto pela URL e a tela funciona por completo (atribuir e revogar), apesar de o item Permissões não aparecer no menu lateral da unidade para nenhum dos dois. O gate do menu (requiredTenantPermission: 'role:read', checado no grupo) é mais restritivo do que o gate da rota (role:read/role:manage resolvido na unidade da URL, via permissionGuard(..., 'route')) — o mesmo padrão de divergência menu-vs-rota já confirmado em Administração.
3. read_only e financial são negados também na unidade. Ao contrário de administrator/manager, esses dois perfis não conseguem abrir /admin/company/:id/permissions nem pela URL direta — são redirecionados para /admin/tenant, indicando que o papel de sistema Read only/Financial não inclui role:read (ou unit:read) suficiente na unidade para passar no guard da rota.

Estado sem grupo selecionado

Ao abrir /admin/roles como administrador de plataforma — que não tem nenhum grupo padrão, já que não possui atribuição de tenant — o filtro Grupo começa vazio e a tabela mostra "Nenhum papel encontrado.", sem nenhum aviso de que é preciso escolher um grupo primeiro. A busca só dispara depois que a pessoa seleciona um grupo no filtro.

Fora do escopo desta doc

• Cadastro de usuário (a linha "usuários" — /admin/users) não é coberto aqui.
• Associar usuários a uma unidade (app-associate-users, usado na lista de Unidades e no wizard de criação de grupo, cobertos em Administração) também concede um papel ao associar — reaproveita a mesma chamada roleApi.assignUser(...) da atribuição de papéis —, mas é um passo secundário de outra tela, não uma tela de RBAC dedicada. Não é detalhado aqui.
• O componente organization-administration (pasta src/app/features/organization-administration) não é uma tela de papéis/permissões, apesar do nome: ele reúne três formulários reutilizados por outras telas — company-form (dados da unidade), user-form (dados do usuário) e associate-users (o modal citado acima). Confirmamos isso lendo o código; nenhum desses três lida com o catálogo de permissões ou políticas ABAC.

Páginas deste módulo

Página	Cobre
Papéis e políticas	/admin/roles, /admin/tenant/:id/permissions — catálogo de papéis, criar/editar/clonar papel, aba Políticas (ABAC): listar, criar e editar
Permissões da unidade	/admin/company/:id/permissions — atribuir e revogar papel por membro da unidade, papéis herdados do grupo vs. diretos

Relacionado

• ⚙️ API: Authorization — visão geral
• 🗂️ Administração — mesmo padrão de guard de menu vs. guard de rota, e onde vive a associação de usuário a unidade
• 🔐 Autenticação — login e MFA usados para testar os perfis