Perfis de acesso¶
O acesso tem duas camadas, e confundi-las é a origem de mais de um defeito já corrigido em produção.
| Camada | Responde | Mora em |
|---|---|---|
| Permissão | Esta pessoa abre esta tela? | permissions |
| Vínculo | Esta pessoa pode agir sobre este registro? | <entidade>_access, *_shares |
Permissão de tela não decide acesso a registro
Quem pode abrir a tela de conversas não tem, por isso, acesso a todas as conversas. Quem pode agir sobre este número, esta conversa ou este funil vem do vínculo. Ver AD-016 e AD-020.
Os cinco perfis de fábrica¶
| Perfil | Alcance | Protegido |
|---|---|---|
| Administrador | Todas as permissões e todos os pipelines | Não |
| Secretaria | Agenda completa, alunos, tutores, sessões, vendas, mentorias e conversa de WhatsApp | Não |
| Tutor | Apenas a própria agenda, mais leitura de alunos, tutores e especialidades | Não |
| Financeiro | Dashboard, financeiro e alunos | Não |
| Aluno | Somente leitura dos próprios dados | Não |
Perfis novos podem ser criados pela tela de Perfis. Os cinco acima são o que o seeder garante.
O que cada um recebe, em detalhe¶
| Perfil | Recebe | Não recebe |
|---|---|---|
| Administrador | Tudo, por sincronização com a lista inteira de permissões | — |
| Secretaria | dashboard, agenda, alunos, tutores, sessoes, vendas; especialidades em ver e gerenciar; formas de pagamento em leitura; WhatsApp em conversas, busca e log, ver e enviar |
Configurações, auditoria, comercial, resto do financeiro |
| Tutor | agenda exceto a tela de todas as agendas; tutores; alunos em leitura; especialidades em leitura; dashboard em leitura; WhatsApp em leitura exceto instâncias |
Ver todas as agendas, responder no WhatsApp, configurações |
| Financeiro | dashboard, financeiro, alunos |
Agenda, WhatsApp, comercial |
| Aluno | Apenas a ação de ver, em agenda, alunos e mentorias |
Tudo o que altera |
O Tutor vê a própria agenda por ausência de permissão
Ele não recebe a permissão de ver todas as agendas. O recorte acontece porque essa permissão falta, não porque exista uma regra "só a própria". Dar essa permissão a ele abre todas.
Como uma permissão é nomeada¶
São 70 permissões, no formato módulo.tela.ação, com unicidade na trinca. Os módulos são:
agenda · alunos · auditoria · comercial · configuracoes · dashboard · especialidades · financeiro · mentorias · sessoes · tutores · vendas · whatsapp
Permissão nova entra por migration, nunca só por seeder
O deploy de produção roda apenas migrate --force, sem seed. Uma permissão declarada só no seeder nunca chega à produção. Ver AD-010.
Os vínculos que existem hoje¶
| Vínculo | Liga | Habilidades |
|---|---|---|
profile_pipeline_access |
Perfil a pipeline | ver, editar |
whatsapp_instance_shares |
Usuário a instância de WhatsApp | atender |
A ausência de linha é a negativa. Não existe estado "negado" gravado, então "ninguém até autorizar" é o padrão sem que a criação do registro escreva nada.
A armadilha da relação com colunas escolhidas
Carregar uma relação pedindo colunas (with('instance:id,label')) devolve nulo em silêncio para o que ficou de fora. Numa pergunta de autorização isso nega acesso a quem tem. Predicado que decide acesso resolve o dado que falta em vez de responder errado.
Tela inicial¶
Cada perfil declara onde começa depois do login. Antes disso, todo mundo caía no Dashboard, e um perfil sem a permissão de dashboard recebia um erro vermelho que não distinguia "você não tem acesso" de "a rede falhou".
Auditoria¶
As alterações são registradas em audit_logs, e o módulo auditoria tem permissão própria. Só o Administrador a recebe de fábrica.