🛡️ Sistema de Permissionamento Hierárquico - Documentação Completa
📋 Visão Geral
O Sistema de Permissionamento Hierárquico é responsável por controlar o acesso de usuários a diferentes níveis da estrutura organizacional com regras de cascata automática. Permite atribuir permissões baseadas na hierarquia (Instituição → Unidade → Turma → Horário) onde permissões de nível superior concedem automaticamente acesso aos níveis inferiores.
Estrutura Hierárquica
Instituição (Nível 1)
├── Unidade (Nível 2)
├── Turma (Nível 3)
├── Horário (Nível 4)
Regra de Cascata: Uma permissão em nível superior concede acesso automático a todos os níveis inferiores.
Tipos de Hierarquia
- Instituicao (1): Acesso total a todas as unidades, turmas e horários da instituição
- Unidade (2): Acesso a todas as turmas e horários da unidade específica
- Turma (3): Acesso a todos os horários da turma específica
- Horario (4): Acesso apenas ao horário específico
Conceitos Importantes
HierarquicoId
O hierarquicoId deve sempre referenciar o ID real da entidade no nível hierárquico correspondente:
- Se
tipoHierarquico = 1 (Instituicao), então hierarquicoId = ID da instituição (ex: 2)
- Se
tipoHierarquico = 2 (Unidade), então hierarquicoId = ID da unidade (ex: 2)
- Se
tipoHierarquico = 3 (Turma), então hierarquicoId = ID da turma (ex: 3)
- Se
tipoHierarquico = 4 (Horario), então hierarquicoId = ID do horário (ex: 1)
TipoUsuarioId
O tipoUsuarioId referencia o ID da relação na tabela relacoes:
- ID=1: Responsável
- ID=2: Familiar
- ID=3: Professor
- ID=4: Treinador
- ID=5: Coordenador
- ID=6: Monitor
- ID=7: Admin (após executar o script de inserção)
🎯 Endpoints Disponíveis
1. GET /api/UsuarioPermissoes
Obter Lista de Permissões
- Descrição: Retorna uma lista completa de todas as permissões de usuários cadastradas no sistema
- Método: GET
- Autenticação: Requerida (JWT Bearer Token)
- Parâmetros: Nenhum
- Resposta: Array de objetos UsuarioPermissaoReadDto
- Uso: Utilizado em dashboards administrativos, relatórios e listagens gerais
2. POST /api/UsuarioPermissoes
Criar Nova Permissão
- Descrição: Cria uma nova permissão hierárquica para um usuário
- Método: POST
- Autenticação: Requerida (JWT Bearer Token)
- Body: CriarUsuarioPermissaoRequest com dados obrigatórios
- Resposta: UsuarioPermissaoReadDto criado com ID gerado
- Uso: Formulários de atribuição de permissões
3. POST /api/UsuarioPermissoes/verificar
Verificar Permissão
- Descrição: Verifica se um usuário possui permissão para acessar um recurso específico na hierarquia
- Método: POST
- Autenticação: Requerida (JWT Bearer Token)
- Body: VerificarPermissaoRequest
UsuarioId: ID do usuário
TipoHierarquico: Tipo do nível hierárquico
HierarquicoId: ID do recurso na hierarquia
- Resposta: VerificacaoPermissaoResultDto
- Uso: Validação de acesso antes de operações
4. GET /api/UsuarioPermissoes/{id}
Obter Permissão por ID
- Descrição: Retorna os dados completos de uma permissão específica
- Método: GET
- Autenticação: Requerida (JWT Bearer Token)
- Parâmetros:
id (path): ID único da permissão
- Resposta: UsuarioPermissaoReadDto completo
- Uso: Visualização de permissão individual, edição de dados
5. PUT /api/UsuarioPermissoes/{id}
Atualizar Permissão
- Descrição: Atualiza os dados de uma permissão existente
- Método: PUT
- Autenticação: Requerida (JWT Bearer Token)
- Parâmetros:
id (path): ID único da permissão
- Body: UsuarioPermissaoUpdateDto com dados atualizados
- Resposta: UsuarioPermissaoReadDto atualizado
- Uso: Formulários de edição de permissões
6. POST /api/UsuarioPermissoes/pesquisar
Pesquisar Permissões
- Descrição: Realiza busca de permissões com base em critérios específicos
- Método: POST
- Autenticação: Requerida (JWT Bearer Token)
- Body: PesquisarPermissoesRequest com filtros de busca
- Resposta: Pesquisa<UsuarioPermissaoReadDto> com resultados paginados
- Uso: Funcionalidade de busca e filtros avançados
7. GET /api/UsuarioPermissoes/usuario/{usuarioId}
Obter Permissões por Usuário
- Descrição: Retorna todas as permissões de um usuário específico
- Método: GET
- Autenticação: Requerida (JWT Bearer Token)
- Parâmetros:
usuarioId (path): ID único do usuário
- Resposta: Array de objetos UsuarioPermissaoReadDto
- Uso: Visualização de permissões do usuário, auditoria de acesso
8. POST /api/UsuarioPermissoes/inativar/{id}
Inativar Permissão
- Descrição: Inativa uma permissão específica sem removê-la do sistema
- Método: POST
- Autenticação: Requerida (JWT Bearer Token)
- Parâmetros: ID da permissão no path
- Resposta: UsuarioPermissaoReadDto inativado
- Uso: Revogação temporária de permissões
9. POST /api/UsuarioPermissoes/reativar/{id}
Reativar Permissão
- Descrição: Reativa uma permissão que foi previamente inativada
- Método: POST
- Autenticação: Requerida (JWT Bearer Token)
- Parâmetros:
id (path): ID da permissão
- Resposta: UsuarioPermissaoReadDto reativado
- Uso: Restauração de permissões temporariamente revogadas
10. GET /api/UsuarioPermissoes/hierarquicas/{usuarioId}
Obter Permissões Hierárquicas
- Descrição: Retorna todas as permissões hierárquicas de um usuário incluindo permissões de cascata
- Método: GET
- Autenticação: Requerida (JWT Bearer Token)
- Parâmetros:
usuarioId (path): ID único do usuário
- Resposta: Array de objetos UsuarioPermissaoReadDto com permissões hierárquicas
- Uso: Verificação de acesso completo, auditoria de permissões
11. POST /api/Atletas/{id}/inativar
Inativar Atleta
- Descrição: Inativa um atleta no sistema (soft delete)
- Método: POST
- Autenticação: Requerida (JWT Bearer Token)
- Parâmetros:
id (path): ID único do atleta
- Resposta: Confirmação de inativação
- Uso: Remoção de atletas sem exclusão permanente
12. GET /api/hierarquia/usuario/{usuarioId}
Obter Hierarquia Completa por Usuário
- Descrição: Retorna automaticamente a estrutura hierárquica completa (Instituição → Unidade → Turma → Horários) baseada nas permissões do usuário. O sistema identifica a permissão de maior nível (menor valor de TipoHierarquico) e retorna todos os dados dos níveis inferiores. Níveis acima da permissão retornam arrays vazios.
- Método: GET
- Autenticação: Requerida (JWT Bearer Token)
- Parâmetros:
usuarioId (path): GUID do usuário
- Resposta: Estrutura hierárquica completa com Instituição, Unidades, Turmas e Horários
- Comportamento:
- Se o usuário tiver múltiplas permissões, utiliza a de maior nível (ex: Instituição prevalece sobre Unidade)
- Retorna arrays vazios para níveis sem permissão
- Inclui automaticamente todos os usuários vinculados aos horários
- Uso: Dashboards personalizados, visualização de dados de acordo com permissões, relatórios hierárquicos
🔧 Modelo de Dados
Estrutura da Permissão
{
"id": 1,
"usuarioId": "user-123",
"tipoHierarquico": "Instituicao",
"hierarquicoId": 1,
"tipoUsuarioId": 7,
"status": true,
"dataCriacao": "2024-12-20T10:00:00Z",
"dataAtualizacao": "2024-12-20T10:00:00Z"
}
🔐 Autenticação e Autorização
Todos os endpoints requerem:
- JWT Bearer Token no header
Authorization
- Permissões específicas baseadas na hierarquia:
- Admin: Acesso total ao sistema
- Professor: Acesso limitado por hierarquia
- Responsável: Acesso limitado aos seus atletas
📊 Casos de Uso Principais
1. Criação de Permissão
POST /api/UsuarioPermissoes
Content-Type: application/json
Authorization: Bearer {token}
{
"usuarioId": "user-123",
"tipoHierarquico": "Instituicao",
"hierarquicoId": 1,
"tipoUsuarioId": 7
}
2. Verificação de Permissão
POST /api/UsuarioPermissoes/verificar
Authorization: Bearer {token}
3. Pesquisa de Permissões
GET /api/UsuarioPermissoes/pesquisar
Content-Type: application/json
Authorization: Bearer {token}
{
"tipoHierarquico": "Unidade",
"hierarquicoId": 3,
"tipoUsuarioId": 8
}
4. Listagem de Permissões
GET /api/UsuarioPermissoes
Authorization: Bearer {token}
5. Busca de Hierarquia por Usuário
GET /api/hierarquia/usuario/{usuarioId}
Authorization: Bearer {token}
⚠️ Validações e Regras de Negócio
Validações Obrigatórias
- UsuarioId: Obrigatório, deve existir no sistema
- TipoHierarquico: Obrigatório, enum válido
- HierarquicoId: Obrigatório, deve existir na hierarquia
- TipoUsuarioId: Obrigatório, deve existir em relacoes
- Status: Boolean, padrão true
Regras de Negócio
- Hierarquia cascata: Permissão superior inclui inferiores
- Unicidade: Usuário não pode ter permissão duplicada
- Validação de existência: IDs devem existir nas tabelas
- Status ativo: Permissões inativas não concedem acesso
- Auditoria: Todas as operações são logadas
🚨 Tratamento de Erros
Códigos de Status HTTP
- 200: Sucesso
- 201: Criado com sucesso
- 400: Dados inválidos
- 401: Não autorizado
- 403: Acesso negado
- 404: Permissão não encontrada
- 409: Conflito (Permissão já existente)
- 500: Erro interno do servidor
Formato de Erro
{
"error": "string",
"message": "string",
"details": "string",
"timestamp": "datetime"
}
📈 Performance e Limitações
Limitações
- Paginação: Listas retornam máximo 100 registros por página
- Rate Limiting: 1000 requests por hora por usuário
- Timeout: 30 segundos por requisição
Otimizações
- Cache: Permissões são cacheadas por 10 minutos
- Índices: Busca otimizada por UsuarioId e HierarquicoId
- Compressão: Respostas comprimidas com gzip
🔄 Integração com Outros Módulos
Módulos Relacionados
- Usuários: Associação obrigatória
- Hierarquia: Instituições, Unidades, Turmas
- HierarquiaController: Visualização hierárquica baseada em permissões (endpoint GET /api/hierarquia/usuario/{usuarioId})
- Relacoes: Tipos de usuário (Admin, Professor, etc.)
- Auditoria: Log de alterações de permissão
- Relatórios: Análise de permissões
📱 Uso em Aplicações
Web App
- Painel de controle de permissões
- Gestão de usuários e hierarquias
- Relatórios de acesso e auditoria
Mobile App
- Verificação de permissões em tempo real
- Controle de acesso móvel
- Gestão simplificada de permissões
🛠️ Manutenção e Monitoramento
Logs Importantes
- Criação de novas permissões
- Atualizações de dados sensíveis
- Tentativas de acesso não autorizado
- Erros de validação
Métricas Monitoradas
- Número de permissões ativas
- Taxa de sucesso das operações
- Tempo de resposta dos endpoints
- Uso de recursos por endpoint
📚 Exemplos Práticos
Fluxo Completo de Permissão
- Validação de dados no backend pela própria API
- POST /api/UsuarioPermissoes com dados validados
- Verificação de hierarquia automática
- Criação de permissão no sistema
- Propagação de acesso aos níveis inferiores
Fluxo de Verificação de Permissão
- POST /api/UsuarioPermissoes/verificar com dados do usuário
- Busca de permissões hierárquicas
- Aplicação de regras de cascata
- Retorno de acesso permitido/negado
Exemplo de Hierarquia por Usuário
Cenário 1: Usuário com permissão de Instituição
Quando o usuário possui permissão de nível Instituição (TipoHierarquico = 1), o sistema retorna toda a cascata hierárquica:
{
"instituicao": [
{
"id": 2,
"nome": "01 - Projeto Veleiros",
"local": "São Paulo, SP",
"tipo": 1
}
],
"unidades": [
{
"id": 1,
"nome": "Unidade Centro",
"local": "Centro",
"tipo": 1,
"instituicaoId": 2,
"instituicaoNome": "01 - Projeto Veleiros"
}
],
"turmas": [
{
"id": 3,
"nome": "Futsal Infantil",
"status": true,
"unidadeId": 1,
"unidadeNome": "Unidade Centro",
"responsavelNome": "João Silva",
"alunosCount": 15
}
],
"horarios": [
{
"id": 10,
"turmaId": 3,
"turmaNome": "Futsal Infantil",
"descHorario": "Segunda 08:30-10:30",
"usuarios": [
{
"id": 28,
"usuarioId": "guid-123",
"usuarioNome": "Maria Santos",
"papelId": 1,
"papelNome": "Aluno"
}
]
}
]
}
Cenário 2: Usuário com permissão de Turma
Quando o usuário possui permissão de nível Turma (TipoHierarquico = 3), o sistema retorna arrays vazios para níveis superiores (Instituição e Unidades):
{
"instituicao": [],
"unidades": [],
"turmas": [
{
"id": 3,
"nome": "Futsal Infantil",
"status": true,
"unidadeId": 1,
"unidadeNome": "Unidade Centro",
"responsavelNome": "João Silva",
"alunosCount": 15
}
],
"horarios": [
{
"id": 10,
"turmaId": 3,
"turmaNome": "Futsal Infantil",
"descHorario": "Segunda 08:30-10:30",
"usuarios": [...]
}
]
}
Versão: 1.0
Última Atualização: Outubro de 2025
Responsável: Equipe de Desenvolvimento CordenaAi