48 lines
2.2 KiB
Plaintext
48 lines
2.2 KiB
Plaintext
🔁 CONTEXTO DO PROJETO (SaaS multi-tenant)
|
|
|
|
Stack:
|
|
- Supabase
|
|
- Multi-tenant por clinic/tenant
|
|
- Assinaturas por tenant (subscriptions.tenant_id)
|
|
- Controle de features: features, plan_features, subscription_intents, entitlementsStore, view v_tenant_entitlements
|
|
- Ativação manual: activate_subscription_from_intent()
|
|
- Merge concluído: agenda_online → online_scheduling.manage
|
|
- Entitlements e bloqueio PRO no menu funcionando
|
|
- Signup + intent funcionando; ativação cria subscription ativa; view retorna feature correta
|
|
|
|
Modelo de “Contas” decidido:
|
|
- Auth user (login) ≠ Clínica (tenant)
|
|
- Clínica = tenant; Usuário pode ser dono/admin de clínica e também profissional
|
|
- Clínica convida usuários (tenant_members). Usuário pode aceitar/recusar.
|
|
- Profissional pode trabalhar anos e depois sair: clínica mantém registros; profissional mantém histórico (audit trail), sem acesso após saída.
|
|
|
|
Regras de offboarding:
|
|
- Profissional só pode sair se NÃO houver agenda futura atribuída a ele.
|
|
- Se houver, cria “pedido de saída” e admin precisa realocar/cancelar; depois finaliza saída.
|
|
|
|
Tabelas existentes:
|
|
- tenant_members: (id uuid pk, tenant_id uuid, user_id uuid, role text, status text, created_at timestamptz)
|
|
- UNIQUE (tenant_id, user_id) atualmente
|
|
- Agenda: agenda_eventos, agenda_excecoes, agenda_configuracoes, agenda_regras_semanais
|
|
- Outros: subscriptions, subscription_intents, plan_features, features, subscription_events
|
|
|
|
O que estamos fazendo agora:
|
|
- Ajustar modelo de membership lifecycle e offboarding (exit_requests)
|
|
- Garantir integridade: histórico de vínculos + auditoria + bloqueio de saída com agenda futura
|
|
- Implementar SQL + RPC + RLS + UI (passo a passo)
|
|
|
|
✔ subscriptions
|
|
Representa o plano da clínica (tenant)
|
|
✔ tenant_members
|
|
Define quais usuários pertencem à clínica
|
|
✔ entitlements
|
|
|
|
Define o que aquela clínica pode usar
|
|
|
|
Dados que faltam confirmar:
|
|
1) Estrutura de agenda_eventos (colunas e como relaciona com profissional)
|
|
2) Valores usados em tenant_members.status (active/invited/etc)
|
|
3) Estratégia de reentrada: remover UNIQUE (tenant_id,user_id) e usar unique parcial por status ativo/convite
|
|
4) Se existe tabela public.users como espelho do auth.users
|
|
|