tiagoandClaude Sonnet 5
323912748f
Adiciona o frontend Next.js em frontend/ (setup, design system, autenticação/tema, layout/navegação, área master, área tenant completa: clientes, produtos, vendas, recebimentos, whatsapp, e-mail, alertas, equipe e perfil). Estende o backend de forma aditiva e autorizada: cookie httpOnly para refresh token (Etapa 13) e CRUD de equipe + edição de perfil do tenant (Etapa 18, módulo src/modules/equipe/ novo e PUT /tenant/perfil). Detalhes completos em Etapas/V2/*. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
98 lines
4.5 KiB
Markdown
98 lines
4.5 KiB
Markdown
# Etapa 18 — Área Tenant: Integrações, Alertas, Equipe e Perfil
|
|
|
|
## Contexto do projeto
|
|
|
|
Continuação do frontend do **SeConectai Vendas**. Já existem: setup,
|
|
design system, autenticação/tema, layout/navegação, área master
|
|
completa, e clientes/produtos/vendas/recebimentos no painel do tenant.
|
|
Esta etapa fecha o painel do tenant com as telas de configuração:
|
|
integrações de mensageria, templates/logs de alerta próprios do tenant,
|
|
gestão da equipe e personalização whitelabel — consumindo os endpoints
|
|
das Etapas 4, 7 e 8 do backend.
|
|
|
|
## Objetivo desta etapa
|
|
|
|
Telas de `/app/whatsapp`, `/app/email-config`, `/app/alertas/*`,
|
|
`/app/equipe` e `/app/perfil`.
|
|
|
|
## Tarefas
|
|
|
|
1. **`/app/whatsapp`**
|
|
- Lista de instâncias WhatsApp do tenant (pode ser mais de uma,
|
|
conforme limite do plano), com status (`desconectado`,
|
|
`conectando`, `conectado`, `erro`) via `StatusPill`.
|
|
- Ação "Nova instância" (respeitando limite do plano — mostrar
|
|
mensagem clara se atingido).
|
|
- Fluxo de conexão: ao criar/selecionar uma instância, mostrar o QR
|
|
code retornado pela API (imagem), com polling automático do status
|
|
a cada poucos segundos até detectar `conectado` (parar o polling
|
|
nesse momento e mostrar sucesso).
|
|
- Botão de teste de envio (número + mensagem) com feedback claro.
|
|
- Ação de desconectar/remover instância, com confirmação.
|
|
|
|
2. **`/app/email-config`**
|
|
- Toggle "Usar configuração padrão da plataforma" vs "Usar meu
|
|
próprio SMTP" — ao desativar o padrão, exibir e exigir os campos de
|
|
SMTP próprio.
|
|
- Botão de teste de envio (e-mail de destino) com feedback claro.
|
|
- Senha do SMTP: campo tipo password, nunca pré-preenchido com o
|
|
valor real ao editar (mesma lógica de segurança da API key da
|
|
Evolution na área master).
|
|
|
|
3. **`/app/alertas/templates`**
|
|
- Mesma lógica de editor da Etapa 15 (master), mas aqui os templates
|
|
são do tenant, com fallback visual indicando quando um tipo/canal
|
|
ainda não tem template próprio e está usando o padrão da
|
|
plataforma (ex: badge "usando padrão da plataforma" com opção de
|
|
"criar meu próprio").
|
|
|
|
4. **`/app/alertas/logs`**
|
|
- Listagem de `alert_logs` filtrada para os alertas enviados pelo
|
|
tenant (para os próprios `customers` dele), com os mesmos filtros
|
|
da tela master (canal, status, período) e expansão de linha para
|
|
ver conteúdo enviado/erro.
|
|
|
|
5. **`/app/equipe`** (visível só para `tenant_admin`, conforme já
|
|
controlado no layout da Etapa 14)
|
|
- Listagem dos `tenant_users` do tenant, com papel (`role`) e status
|
|
ativo/inativo.
|
|
- Convite/criação de novo usuário: nome, e-mail, papel, senha
|
|
provisória (mesma UX de exibir e avisar sobre a senha gerada, como
|
|
na criação de tenant pelo master).
|
|
- Ação de desativar usuário e de alterar papel.
|
|
|
|
6. **`/app/perfil`**
|
|
- Dados da empresa (nome fantasia, razão social — parte editável
|
|
dentro do que o backend permitir ao tenant alterar).
|
|
- **Upload de logo**: componente de upload com preview imediato,
|
|
validação de tipo/tamanho no client antes de enviar (espelhando as
|
|
regras do backend: png/jpg/svg, até 2MB), e ação de remover logo
|
|
(volta ao padrão da plataforma).
|
|
- **Seletor de cor primária**: color picker, com preview ao vivo de
|
|
como a cor fica aplicada nos componentes principais (ex: mostrar um
|
|
botão de exemplo com a cor escolhida antes de salvar), incluindo o
|
|
aviso de contraste automático descrito na Etapa 13.
|
|
- Ao salvar, o tema da aplicação inteira (sidebar, botões) deve
|
|
atualizar imediatamente, sem precisar recarregar a página.
|
|
|
|
## Critérios de aceite
|
|
|
|
- [ ] Fluxo completo de conexão de instância WhatsApp funciona (criar →
|
|
escanear QR → status muda para conectado automaticamente via
|
|
polling)
|
|
- [ ] Teste de envio de WhatsApp e de e-mail funcionam com feedback
|
|
claro de sucesso/erro
|
|
- [ ] Alternância entre SMTP próprio e padrão da plataforma funciona
|
|
corretamente, exigindo campos quando aplicável
|
|
- [ ] Templates do tenant mostram claramente quando estão usando
|
|
fallback do padrão da plataforma
|
|
- [ ] Logs de alerta do tenant mostram apenas os alertas dele
|
|
(isolamento correto)
|
|
- [ ] CRUD de equipe funciona e respeita a visibilidade só para
|
|
`tenant_admin`
|
|
- [ ] Upload de logo funciona com validação client-side e preview
|
|
imediato
|
|
- [ ] Alteração de cor primária reflete instantaneamente em toda a
|
|
aplicação após salvar, sem reload manual
|
|
- [ ] Todas as telas testadas em 375px, 768px e 1280px
|