Sistema de Permissões Granular

📚 Referência completa e treinamento: este módulo tem uma lição detalhada de certificação — passo a passo de todas as telas, campos e regras.
🟠 PLANEJADO — ainda NÃO está em produção (GitLab #395). Esta página descreve um refactor planejado do controle de permissões. O modelo em produção hoje é o clássico: papel (Role) + ações fixas (VIEW/CREATE/UPDATE/DELETE) por módulo — ver Configurações → Usuários e Permissões. O conteúdo abaixo é o desenho futuro, no roadmap.

Modelo atual (produção) vs. modelo planejado

Atual (produção)Planejado (#395)
Papéis por usuário1 (Role)N (PerfilPermissao)
Ações4 fixas10+ configuráveis
GranularidadePor móduloPor permissão
GruposNãoGrupoPermissao
CustomizaçãoHard-codedTela admin
Integração KeycloakNãoSim (sincroniza)

Models previstos (8)

Endpoints (9+ endpoints)

MétodoEndpointFunção
POST/perfil/grupoCriar GrupoPermissao
GET/perfil/grupoListar grupos do banco
GET/perfil/grupo-keycloakListar grupos no Keycloak
GET/perfil/permissoesListar todas permissões
GET/perfil/colaborador/:id/permissoesPermissões resolvidas do colaborador
PUT/perfil/grupo/:id/permissoesEditar permissões do grupo
PUT/perfil/colaborador/:id/permissoesEditar permissões do colaborador
GET/perfil/perfil-permissoesListar PerfilPermissao
POST/perfil/perfil-permissoesCriar PerfilPermissao

Exemplo de Hierarquia

GrupoPermissao "Equipe Recepção"
├─ PerfilPermissao "Recepcionista Júnior"
│  ├─ Permissao "AGENDAMENTO"
│  │  ├─ PermissaoAcao VIEW
│  │  ├─ PermissaoAcao CREATE
│  │  └─ PermissaoAcao UPDATE (não DELETE)
│  ├─ Permissao "PACIENTE"
│  │  ├─ PermissaoAcao VIEW
│  │  ├─ PermissaoAcao CREATE
│  │  └─ PermissaoAcao UPDATE
│  └─ Permissao "FILA_ATENDIMENTO" (VIEW)
└─ PerfilPermissao "Recepcionista Sênior"
   ├─ Tudo do Júnior +
   ├─ AGENDAMENTO.DELETE
   ├─ PACIENTE.DELETE
   ├─ AUTORIZACAO.CREATE/VIEW
   └─ Permissao DISCOUNT_NIVEL_1 (até 5%)

Colaborador "Maria" → vinculada ao PerfilPermissao "Recepcionista Sênior"
                    → vinculada ao Grupo "Equipe Recepção Centro"
                    → vinculada ao Keycloak Group "rabi-recep" (SSO)

Como o sistema resolve permissões

  1. Login via Keycloak → token JWT com sub (userId)
  2. API valida token + carrega Colaborador
  3. Recupera todos os PerfilPermissao via ColaboradorPermissao
  4. União: SET de PermissaoAcao = SOMA de todos os perfis
  5. Compara com permissão exigida pela rota
  6. Permite ou bloqueia (HTTP 403)
  7. Cache de 5 min (invalida ao alterar perfil)

Migração do modelo antigo

Script one-shot migra Roles existentes:

Após migração, admin pode customizar perfis ou criar novos. Role antigo não é deletado (rollback possível).

Sincronização Keycloak

Sistema mantém vínculo bidirecional com grupos do Keycloak (rabi-recep, rabi-medicos, etc):

Permissões especiais

Algumas permissões têm regras adicionais (configurável via ParametrosDoSistema):

Auditoria

Toda alteração em perfis/grupos/permissões registra em Actions com:

Telas (Frontend)

Componentes