tiago/SeConectai_Vendas
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
main
SeConectai_Vendas/Etapas/V2/18-frontend-area-tenant-integracoes-perfil.md
T
tiagoandClaude Sonnet 5 323912748f Frontend completo (Etapas 11-18) e extensões de backend (Etapas 13 e 18) 
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>
2026-08-16 09:41:13 -03:00

4.5 KiB
Raw Permalink Blame History

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
Reference in New Issue View Git Blame Copy Permalink