Super Admin — Redesign e Expansão
Status: planejamento — redesign completo ainda não iniciado Criado em: 2026-04-17 Patch v1 aplicado (2026-04-20):/admin/users,/admin/units,/admin/modalitiesganharam selects em cascata (clínica → unidade) em vez de inputs de UUID cru; headers mostram nomes em vez de IDs. Foi um fix mínimo pré-homolog para destravar teste de criação de usuários — não é o redesign deste doc. Todas as demais dores abaixo continuam válidas. Bloqueado por: decisões pendentes (§4) e pelo refactor de memberships (MEMBERSHIPS_REFACTOR.md) Relação com RBAC Fase 2: este doc substitui o escopo original da Fase 2 e amplia para além de UI (onboarding, gateways, memberships)
1. Por que fazer
1.1 Como o painel /admin está hoje
CRUD cru. Quatro telas soltas (tenants, units, modalities, users), cada uma com lista + formulário. Sem fluxo, sem consolidação, sem onboarding.
1.2 Problemas reais
- Onboarding caótico — criar uma clínica nova exige: criar tenant → criar units → cadastrar modalities (AET + vpn_ip) → criar usuários. 4 telas separadas, sem wizard, sem validação cruzada.
- Sem visão consolidada — impossível olhar para uma clínica e ver de uma vez: quantas units, quais gateways, quantos users, quais memberships.
- Gateways são cadastro seco — só um form com AET, unit_id, vpn_ip. Sem teste de conectividade, sem “mover aparelho entre units”, sem histórico.
- Memberships não têm UI — quando o refactor de memberships entrar, vai precisar de gestão completa (criar membership, ativar/desativar, listar por user, listar por tenant).
- Sem impersonação — super admin precisa debugar algo no tenant X? Hoje não tem como “ver como um user do tenant X veria”. Precisa logar com outra conta.
2. Cenários reais
Cenário A — Onboarding de clínica nova A Technik vende para uma nova clínica (Clínica Delta). Super admin precisa: criar tenant, criar 3 units, cadastrar 2 gateways, criar 1 tenant_admin + 3 doutores + 2 recepcionistas. Hoje: 9 clicks de “criar” em 4 telas diferentes, sem checklist. Cenário B — Migração de aparelho Clínica Alfa move um tomógrafo da Unidade Centro para a Unidade Zona Sul. Aparelho tem mesmo AET. Hoje: não tem UI para isso. Super admin precisa editar a modality manualmente. Cenário C — Auditoria de clínica Super admin quer olhar “como está a Clínica Gamma hoje” — quantos estudos últimos 30 dias, quantos laudos pendentes, quantos gateways online, últimos logins. Hoje: impossível — precisa consulta direta no banco. Cenário D — Debugar bug reportado por tenant Tenant admin reporta “laudo do estudo X não imprime”. Super admin precisa reproduzir. Hoje: pede credenciais do user ou loga com conta de super admin (scope diferente do user que reportou). Cenário E — Gerenciar memberships (pós-refactor) Médico terceirizado Dr. João pede acesso a mais uma clínica. Hoje: não existe UI; depois do refactor de memberships, super admin precisa buscar user por CRM, validar, criar membership, definir role.3. Escopo proposto (features)
3.1 Dashboard consolidado por tenant
Página/admin/tenants/{id} com:
- Resumo: N units, N users, N gateways, N estudos últimos 30 dias, N laudos pendentes
- Aba “Units”: lista com criar/editar/desativar
- Aba “Usuários”: lista com filtro por role, status, unit
- Aba “Gateways”: lista com teste de conectividade
- Aba “Memberships” (pós-refactor): gestão de vínculos
- Aba “Atividade”: últimos logins, últimos estudos ingeridos, jobs falhos
3.2 Onboarding guiado (wizard)
Botão “Nova clínica” inicia wizard:- Dados da clínica (nome, slug, logo, CNPJ opcional)
- Primeira unidade (nome, endereço)
- Primeiro gateway (AET + vpn_ip) — opcional, pode pular
- Primeiro tenant_admin (nome, email, CRM se médico)
- Revisar e confirmar
3.3 Gerenciamento de gateways
Por unidade, lista de modalities com:- Status (configurado, conectado, nunca comunicou)
- Último C-STORE recebido
- Teste de conectividade (ping via Orthanc REST API para o IP interno da VPN)
- Ação “Mover para outra unidade”
- Ação “Renomear AET” (com alerta sobre estudos existentes)
3.4 Gerenciamento de memberships (depende do refactor)
Lista de memberships de um user, com:- Adicionar membership (buscar user por CRM/email → escolher tenant/unit/role)
- Editar role
- Ativar/desativar
- Histórico
3.5 Impersonação
Botão “Entrar como” no user: super admin passa a operar como se fosse aquele user, com scope do tenant/unit dele. Toda ação fica registrada em audit trail com flagimpersonated_by_super_admin_id. Sair da impersonação volta ao contexto original.
3.6 Busca global
Campo de busca no header do painel super admin: busca por nome de tenant, slug, CNPJ, email de user, CRM, AET. Útil para suporte (“o Dr. Silva da Clínica Beta não consegue logar”).4. Decisões pendentes
4.1 Onboarding: wizard linear ou abas?
Linear: força ordem (tenant → unit → gateway → user). Pode impedir pular, garante consistência. Abas: flexibilidade, pode criar em qualquer ordem. Pode deixar entidade órfã (tenant sem unit). Proposta: linear, com passos 3 e 4 (gateway e user) opcionais — podem ser adicionados depois. Decisão pendente.4.2 Tenant admin: convite por email ou credencial manual?
Convite: super admin preenche email, sistema manda convite com link mágico. Mais seguro, mais UX profissional. Manual: super admin cria user com senha temporária e passa para o tenant admin de outro jeito (WhatsApp, telefone). Proposta: convite por email se email estiver disponível; fallback manual se não. Decisão pendente.4.3 Impersonação: permitir ou não?
Permitir: resolve muitos casos de suporte. Mas: implicações de privacidade (super admin vê dados clínicos de pacientes). LGPD exige consentimento? Auditoria precisa ser pesada? Não permitir: força suporte via tenant admin enviando print, descrevendo passos etc. Mais lento. Proposta: permitir, com audit trail obrigatório + banner visível “Você está impersonando X” + limite de 1h por sessão. Decisão pendente.4.4 Gateways: teste de conectividade é real ou simbólico?
Real: super admin clica “testar” → backend faz C-ECHO para o gateway via Orthanc. Precisa do Orthanc conectado na VPN, risco de timeout travar UI. Simbólico: só confirma que o gateway está cadastrado e o vpn_ip está reservado. Proposta: real, com spinner e timeout de 10s. Decisão pendente.4.5 Migração de aparelho entre units: permitir alterar AET?
Se Dr. X trocou de tomógrafo, novo aparelho tem AET diferente — seria criação de nova modality. Fácil. Mas se o mesmo aparelho muda de unidade, AET fica igual e só a FKunit_id muda. E os estudos antigos? Estão com unit_id = unidade_velha — vira inconsistência? Re-scope automático?
Proposta: não re-scope automático. Estudos antigos ficam onde estão. Nova ingestão vai para a nova unidade. UI deixa isso claro.
Decisão pendente.
4.6 Renomear AET: bloquear ou só alertar?
AET é chave de resolução de tenant/unit no webhook do Orthanc. Mudar AET de uma modality que já tem estudos associados:- Bloquear: evita inconsistência, mas tira flexibilidade real (clínicas às vezes renomeiam mesmo).
- Só alertar: deixa passar com warning “isso pode confundir busca por estudos antigos”.
4.7 Busca global: escopo (quais entidades)?
Tenant, user, unit, modality, estudo (por StudyInstanceUID)? Proposta: começar com os 4 primeiros (entidades de cadastro); estudo depois. Decisão pendente.4.8 Dashboard consolidado: quais métricas são cruciais?
Propostas:- Volume de estudos últimos 30 dias (linha temporal)
- Laudos pendentes (gauge)
- Jobs falhos (counter)
- Storage usado por tenant (barra)
- Últimos logins por user (tabela)
5. O que NÃO entra neste doc
- Manipulação de conteúdo DICOM (modify, merge, C-GET, C-MOVE) — ver
DICOM_OPERATIONS.md - Modelo de dados de membership — ver
MEMBERSHIPS_REFACTOR.md - Refactor de storage — ver
STORAGE_ARCHITECTURE.md
6. Dependências
| Depende de | Por quê |
|---|---|
MEMBERSHIPS_REFACTOR.md | Gestão de memberships (§3.4) só faz sentido em cima do modelo novo |
| Orthanc configurado para C-ECHO (teste de conectividade §3.3) | Gateway test depende disso |
| Storage com bucket (pós-STORAGE_ARCHITECTURE Fase 1) | Dashboard de uso de storage (§4.8) fica mais preciso com buckets separados |
7. Plano de fases
Fase 0 — Decisões (AGORA)
Fechar as decisões de §4.Fase 1 — Dashboard consolidado por tenant
Sem wizard, sem impersonação. Só a visão unificada (§3.1).Fase 2 — Onboarding guiado
Wizard de criação de clínica (§3.2).Fase 3 — Gerenciamento de gateways
Teste de conectividade + migração + renomeação (§3.3).Fase 4 — Memberships UI
Depois do refactor de memberships. CRUD completo de vínculos (§3.4).Fase 5 — Impersonação
Feature sensível, deixa por último (§3.5).Fase 6 — Busca global
Transversal, valor incremental alto (§3.6).8. Discussões abertas
- Convidar vs criar silenciosamente — quando super admin adiciona user existente a uma clínica, manda email de notificação?
- Multi-idioma no painel — português only? Ou inglês para quando houver super admin de outro país?
- Auditoria de ações do super admin — toda mudança em tenant/unit/user gera log? Ou só ações destrutivas?
- Dashboard: real-time ou cached? — WebSocket ou polling? Para MVP pode ser refresh manual.
- Visão “overview de tudo” — tela inicial do painel super admin lista todos os tenants com métricas-chave de cada um? Ou só busca + “clica no tenant pra ver detalhes”?
- Exportação de dados — super admin pode exportar CSV de estudos de um tenant (para backup, migração, análise)? Ou fica restrito a operações via banco?