Perfis e permissões — Estoque e Pedidos

1 · Perfis do usuário

Marque quantos quiser. As permissões se somam.

Permissões concedidas direto ao usuário

Nenhum perfil traz estas. Quem decide é o Administrador, caso a caso.

Sobre esta combinação

2 · O que essa pessoa vê

Menu lateral

O menu só esconde o caminho. A rota também é protegida por permissão, e a ação passa pela Policy: quem digitar o endereço de uma tela sem acesso recebe “403”.

3 · Matriz de permissões

As colunas dos perfis marcados acima ficam em destaque. Clique no cabeçalho de um perfil para marcá-lo ou desmarcá-lo, ou na coluna “Direto” para conceder a permissão específica.

Permissão	Direto	Tem?

		sim —

4 · A permissão basta? Teste uma ação

O pacote de permissões responde “esse perfil pode fazer esse tipo de coisa?”. A Policy responde “pode fazer nesta linha, agora?”. Para o usuário montado acima, escolha o que ele tenta fazer.

O usuário tenta

O pedido foi feito por Situação do pedido A etapa atual designa o setor ou perfil do usuário?

O sistema recusa com 403 e registra a tentativa. Primeiro motivo: .

Verificado em .

Perfis por município (Spatie Permission com teams)

Os perfis são por tenant: a tabela roles tem team_id igual ao tenant_id. Um município pode ajustar os seus sem afetar os outros.
As permissões são as mesmas para todos: são definidas pelo código, uma por ação do sistema, e ficam numa tabela global.
Os perfis são criados junto com o tenant, já com as permissões da matriz acima.
A atribuição de perfil ao usuário (model_has_roles) também leva o tenant.

// middleware, depois de descobrir o tenant pelo subdomínio
setPermissionsTeamId($tenant->id);

// ao criar o tenant
foreach (array_keys(PerfisPadrao::matriz()) as $nome) {
    $perfil = Role::create(['name' => $nome]);
    $perfil->syncPermissions(PerfisPadrao::matriz()[$nome]);
}

Onde cada coisa é decidida

Pergunta	Quem responde
Este usuário pode abrir a tela de aprovação?	Permissão no middleware da rota e no menu
Pode aprovar este pedido?	Policy do pedido: situação, autor, etapa
A saída passa da quantidade aprovada ou do saldo?	Classe de ação, na transação (e `CHECK` no banco)
Este pedido é de outro município?	Scope do tenant e Row-Level Security: nem chega a existir para o usuário
O módulo está ativo no município?	Middleware `modulo:<nome>`, antes da permissão

public function autorizar(User $user, Pedido $pedido): bool
{
    return $user->can('pedidos.autorizar')
        && $pedido->status === StatusPedido::EnviadoParaAprovacao
        && $pedido->solicitante_id !== $user->id
        && $this->etapaAtualDesigna($pedido, $user);
}

Perguntas para levar à SEMTRAS

Estoque e Distribuição são pessoas diferentes? A análise trata os dois como o setor de Compras. Se for a mesma equipe, os dois perfis podem virar um.
O solicitante vê só os pedidos do seu setor ou também os que ele fez em outro setor onde já trabalhou?
Quem pode cancelar um pedido, e até quando? A matriz assume: o próprio solicitante, enquanto não houve entrega.
Quem recebe a permissão de entrada fora de contrato? Sugestão: o responsável do Estoque, concedida pelo Administrador, cada caso registrado na auditoria.
Quem faz o papel de Administrador no município? Ele não consta no PDF, mas alguém precisa cadastrar usuários e setores.
Os dois setores autorizadores são a NSUAS 1 e a NSUAS 2, numa etapa só: basta um servidor de qualquer um deles. A Policy consulta a etapa configurada. Falta definir se um deles pode rever a decisão do outro.

Perfis do PDF e o Administrador proposto · usuários e cenários fictícios · fonte: docs/requisitos/analise-requisitos.md, seções 2 e 7 (item 1). Configuração do fluxo de autorização em docs/fluxos/00-configurador-autorizacao.html.