data-model · defined
Modelo de dados — Acesso
Esquema lógico de conta, vínculos institucionais e escopo de acesso.
Antes do diagrama
Em linguagem simples, uma pessoa possui uma conta para entrar no SGE e um ou mais vínculos que dizem em que papel ela está trabalhando. O sistema usa esse papel, o campus, o curso aplicável e a relação com o estágio para mostrar apenas as informações necessárias.
O esquema abaixo usa nomes técnicos de tabelas e colunas para atender também a quem desenvolve o sistema. A explicação dos papéis, sem esses termos, está em Pessoas e responsabilidades.
Tabelas de acesso
Diagram Design · Mermaid · arraste para mover · Ctrl/⌘ + scroll para zoom
Renderizando diagrama declarativo…
Leitura semântica
Uma conta exerce vários vínculos; cada vínculo referencia campus e curso, carrega o tipo funcional e define o escopo das Policies.
diagrams/sources/modelo-acesso-erd.mmdA função e o escopo pertencem a affiliations.type, convertido para o enum AffiliationType. Gates e Policies aplicam as regras institucionais sobre esse contexto.
Contexto ativo e autorização nativa
Diagram Design · Mermaid · arraste para mover · Ctrl/⌘ + scroll para zoom
Renderizando diagrama declarativo…
Leitura semântica
A conta autenticada resolve o vínculo ativo da sessão; um Gate valida o contexto e as Policies combinam tipo, campus, curso e estado antes de liberar ações e dados.
diagrams/sources/modelo-acesso-contexto.mmdA caixa operacional usa Affiliation::notifications() após a Policy validar que o vínculo selecionado está ativo e pertence à conta autenticada. O par polimórfico mantém separadas as caixas de vínculos diferentes da mesma conta. User mantém Notifiable, mas recuperação de senha, convite inicial e aviso de novo vínculo são enviados por e-mail e não criam linhas na tabela notifications.
email_messages armazena conteúdo imutável de notificações operacionais e de mensagens administrativas, incluindo conta criada, novo vínculo, alteração de e-mail e alterações administrativas. email_delivery_attempts guarda o destinatário, a autoria solicitante, o contexto do registro afetado e o histórico do transporte. requested_by_affiliation_id identifica quem pediu o envio; scope_context preserva o registro relacionado para definir o escopo mesmo se ele for removido. São papéis distintos: o destinatário pode ser uma pessoa sem conta e não determina o escopo. A consulta atual está disponível somente ao Administrador do Sistema ativo e selecionado, para mensagens relacionadas a contas e vínculos administrativos. Recuperação de senha não cria registros nessas tabelas; registros antigos podem não ter conteúdo persistido.
Convenção de implementação
- um middleware resolve e valida o vínculo ativo da sessão, incluindo
deactivated_at; - Não há
Gate::beforeglobal: Policies revalidam o vínculo ativo e selecionado e aplicam o escopo de cada recurso; - Policies recebem o usuário e resolvem o vínculo ativo por serviço/contexto, verificando
AffiliationType, campus, curso, posse do registro e estado do fluxo; - Blade e Livewire usam a API padrão (
@can,$user->can(),$this->authorize()e middlewarecan:), nunca comparações espalhadas de string; - testes cobrem cada decisão da matriz com vínculo correto, tipo errado, campus errado, vínculo desativado e estado inválido.