GustavoandClaude Sonnet 5 eed473c5f3 fix: telefone de contato sem DDI e updates/excludes que fingiam sucesso
- app/routers/contatos.py: CLIENTE_CONTATO.TELEFONE passa a ser gravado
  sempre com DDI 55 (normalizar_telefone_com_ddi, mesma normalização já
  usada em CLIENTE.TELEFONE/CELULAR) — confirmado no node '10 - Validar
  Telefones' do workflow n8n de produção (ER6Piy9yu93uOVuY) que o
  telefone é usado exatamente como está gravado, sem nenhuma
  normalização própria. Um contato cadastrado pelo painel sem o
  funcionário digitar '55' na frente nunca recebia a chave automática
  por WhatsApp — falha silenciosa, sem nenhum erro visível.

- app/db/clientes.py, app/db/contatos.py, app/db/funcionarios.py:
  excluir_cliente/atualizar_contato/excluir_contato/redefinir_senha
  passam a retornar bool (cur.rowcount > 0) em vez de None — um
  ID inexistente não gera erro nenhum do MySQL (WHERE só não bate com
  nada), então sem checar rowcount o router não tinha como saber que
  não alterou/excluiu nada.

- app/routers/clientes.py, app/routers/contatos.py,
  app/routers/funcionarios.py: editar/excluir/redefinir-senha/
  alternar-ativo passam a checar essa existência e mostrar 'não
  encontrado' em vez de registrar 'sucesso' no log e redirecionar pra
  uma tela que também vai dizer que não encontrou nada.

- app/templates/clientes_lista.html: busca não estava com urlencode nos
  links de paginação/ordenação — um termo de busca com '&' (comum em
  razão social, ex. 'Fulano & Cia') cortava o resto da query string do
  link, perdendo página/ordenação.

Suíte completa (192 testes) passando, com 13 testes novos cobrindo os
casos de 'não encontrado' e o DDI do telefone de contato.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-15 11:50:37 -03:00
2026-08-13 09:39:28 -03:00
2026-08-13 09:39:28 -03:00

painel-clientes-web

Painel administrativo (FastAPI + Jinja2) para gestão de CLIENTE, CLIENTE_CONTATO e geração manual de chave de licenciamento no MySQL do sistema legado.

Proteções: login por sessão em toda rota (cookie assinado — ver seção "Login e permissões" abaixo), CSRF via cookie de duplo envio (app/csrf.py — todo formulário que muda estado embute o mesmo token do cookie csrf_token, definido pelo middleware em app/main.py) e a lista de clientes é paginada (100 por página), com busca e ordenação por código/razão/fantasia/CNPJ.

CODIGO de cliente não aceita duplicado (bloqueio duro, sem bypass) e o formulário de novo cliente já sugere o próximo código sequencial (editável). Só CODIGO, CNPJ, RAZAO e FANTASIA são obrigatórios — os campos de contrato (implantação, mensalidade, juros, datas) podem ficar em branco e recebem default (0,00 / data de hoje).

A rota /log mostra o histórico de ações do painel (tabela LOG_PAINEL, criada no banco de dev — precisa ser criada manualmente em produção também, DDL no início de app/db/log.py) e, se N8N_API_URL/N8N_API_KEY estiverem configuradas (.env.example), os últimos envios automáticos de chave via WhatsApp (lidos da Data Table pagamentos_processados do n8n, somente leitura).

Login e permissões

O painel usa login por sessão (cookie assinado, app/session.py) — não é mais HTTP Basic Auth. Defina SESSION_SECRET no .env (.env.example tem o exemplo); sem isso, uma chave é gerada em memória a cada start do processo, o que derruba todas as sessões ativas a cada restart (funciona, só incomoda).

Cada funcionário (FUNCIONARIO_PAINEL, criada no banco de dev — precisa ser criada manualmente em produção também, DDL no início de app/db/funcionarios.py) tem um perfil: admin (gerencia outros funcionários em /funcionarios: cadastra, edita, redefine senha, ativa/desativa, promove/rebaixa perfil) ou padrão (sem acesso a /funcionarios). Se FUNCIONARIO_PAINEL já existir de uma instalação anterior sem a coluna PERFIL, rode o ALTER TABLE FUNCIONARIO_PAINEL ADD COLUMN PERFIL ... (DDL completo em app/db/funcionarios.py) — precisa ser rodado manualmente em produção também; sem essa coluna, todo login falha com erro 500 (a query de autenticação seleciona PERFIL, que não existe na tabela antiga). O DEFAULT 'ADMIN' desse ALTER TABLE é intencional: todo funcionário cadastrado antes da migração vira admin automaticamente. O sistema nunca deixa ficar sem nenhum admin ativo — rebaixar ou desativar o último admin é bloqueado.

Qualquer usuário logado troca a própria senha em Minha conta (/minha-conta), pedindo a senha atual antes de trocar.

ADMIN_USER/ADMIN_PASSWORD (.env.example) continuam funcionando como conta de bootstrap, sempre com perfil admin — é com ela que você entra a primeira vez para cadastrar o primeiro funcionário, e serve de plano B se a tabela ficar vazia. Login checa primeiro o admin do .env, depois FUNCIONARIO_PAINEL (só contas com ATIVO=1).

Rodando localmente (sem Docker)

  1. Instale as dependências de desenvolvimento:
    pip install -r requirements-dev.txt
    
  2. Defina as variáveis de ambiente necessárias (ADMIN_USER, ADMIN_PASSWORD, DB_HOST, DB_PORT, DB_NAME, DB_USER, DB_PASSWORD, SESSION_SECRET — veja .env.example) diretamente no shell antes de subir a aplicação. SESSION_SECRET é opcional em dev — sem ela, uma chave aleatória é gerada em memória a cada start (sessões caem a cada restart); defina um valor fixo em produção. Importante: apesar de python-dotenv estar nas dependências, nada no código chama load_dotenv() hoje — um arquivo .env sozinho NÃO é lido automaticamente fora do Docker. Exporte as variáveis manualmente (ex.: set -a; source .env; set +a no bash, ou $env:... no PowerShell) ou defina-as por outro meio.
  3. Rode a aplicação:
    uvicorn app.main:app --reload
    
  4. Rodando direto na máquina (fora de container), use DB_HOST=127.0.0.1 (porta 3307, a mesma do container de dev licenciamento-mysql-dev).

Rodando os testes

pytest -v

Os testes usam defaults definidos em tests/conftest.py (equivalentes ao .env.example) e incluem testes de integração que precisam do container MySQL de dev (licenciamento-mysql-dev, 127.0.0.1:3307) rodando.

Rodando via Docker

  1. Copie o arquivo de exemplo de variáveis de ambiente e edite ADMIN_PASSWORD (e demais valores, se necessário):
    cp .env.example .env
    
  2. Suba o container:
    docker compose up -d --build
    
    O docker-compose.yml já usa env_file: .env e mapeia host.docker.internal para o host (via extra_hosts), então o valor padrão DB_HOST=host.docker.internal do .env.example funciona também em hosts Docker Linux, não só no Docker Desktop (Windows/Mac).
  3. A aplicação fica disponível em http://localhost:8010.
S
Description
GTI GERENCIADOR / FISCAL
Readme
11 MiB
Languages
Python 82%
HTML 15.8%
CSS 1.2%
PowerShell 0.6%
Shell 0.2%
Other 0.1%