Diretório de usuários
Tabela fina no plano de controle que resolve uma pergunta: “este e-mail pertence a qual organização?“. Decisão em adr-002-email-unico-global.
O cadastro completo do usuário continua em app_<org>.users — aqui fica só o roteamento do
login e a garantia de unicidade global.
Campos (appstock_core.user_directory)
| Campo | Papel |
|---|---|
email | Único em toda a plataforma. É a chave. |
org_id | FK para ent-organizacao, ON DELETE CASCADE. |
user_id | UUID do usuário dentro do app_<org>. Sem FK (bancos diferentes). |
Para que serve na prática
- Rotear o login. Identificador com
@→ busca aqui → descobre a organização → só então abre sessão noapp_<org>e confere a senha. Ver tela-login. - Impedir e-mail repetido entre organizações. O mod-provision recusa com
ValueError(“e-mail do admin já cadastrado na plataforma”), que o mod-signup traduz em 409.
A regra que atravessa o produto
E-mail de usuário é único na plataforma inteira. Toda operação de criar, editar ou excluir usuário precisa manter este diretório em sincronia — é o tipo de acoplamento que se esquece e gera login quebrado meses depois.
Buracos conhecidos
- Só o admin do provisionamento entra aqui automaticamente. Vale conferir se o cadastro de
usuários (
/admin/users) mantém o diretório em dia em todas as operações — é o ponto de falha mais provável desta tabela. - Multi-org está desenhado e não implementado. Um usuário em duas organizações seriam duas linhas aqui, mas nada no login sabe escolher entre elas.
- Sem
updated_at. Troca de e-mail não deixa rastro.