mirror of https://github.com/melgarafael/DeskcommCRM.git synced 2026-10-02 01:28:34 +08:00

Files

T

PessoaandClaude Opus 5 1604145898 fix(kit): o if que não cerca a criação não isenta, e a tela soma as duas metades

Terceira rodada (4 agentes): as 3 sabotagens com os baselines antigos provam a
régua no arquivo real (cf35c9444: 24 pares — 2 índices, 1 constraint, 21
policies — mais as 2 redefinições; f0ccfe8d0: 21 + 2; 1a97bc37c: 2 + 2), 6
sabotagens do kit e 4 da régua bateram, e o revisor achou um falso negativo
grave, reproduzido pelo cético:

- guardaEm perguntava se o bloco `do` tinha ALGUM `if`, não se a criação estava
  DENTRO dele. Reinstalando o defeito das policies no laço da 0085 e somando um
  `if` neutro em qualquer ponto do mesmo bloco, a régua ficava 15/15 verde.
  Agora só a faixa `if … then … end if` que CERCA a criação decide, e o `if` de
  `create index if not exists` não abre faixa (o que abre tem `then` antes do
  `;`). Caso novo no sintético: criação fora do if, no mesmo bloco.
- `on public.%I` dentro de `execute format` era lido como policy na tabela
  "public" (11 chaves fantasma no arquivo real, contra o escopo escrito).
- `textoDaPolicy` cortava no primeiro `;`, que em 4 comandos cai dentro de um
  comentário `--` (o cae_select final saía truncado). Comentário sai antes.
- a ligação do laço com o localizador de pares passa a ser medida no arquivo
  real: desligá-la deixava o caso das policies verde por omissão.

Kit:
- orientação SOMA as duas metades: com disputa e permissão na mesma lista, a
  tela dizia só "repetir não resolve" e escondia a ação que curava a outra
  metade;
- listar_erros_do_banco usa awk com -v (recuo e máximo viram dado; uma barra no
  recuo quebrava o programa do sed e derrubava o script sob set -e).

Prosa: "a partir da atualização seguinte à v1.28.0" nomeava a release errada —
v1.28.0 é a BASE desta branch. Vira "a seguinte à que instalar esta correção".
Comentário do bloco da 0085 descrevia um laço que não cria mais policy.

Testes: o check do FIM passa a casar o cabeçalho do bloco final (com a frase
antiga ele ficava verde com o bloco apagado); update-guard 85 checks (era 84);
função 44; test-validators 272; régua 16 casos. E o teste vizinho de policies
guardadas saiu de 4,96 s para 13 ms (varredura quadrática sobre 25 mil linhas,
que sob carga passava do limite de 15 s e vermelhava sozinho).

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

2026-09-16 15:39:50 -03:00

3.1 KiB

Raw Permalink Blame History

Atualizando o DeskcommCRM na sua VPS

Saiu uma versão nova? Atualizar é um comando só. Você não precisa saber se a novidade é no código, no banco de dados ou nos dois — o comando cuida de tudo, na ordem certa e com backup automático antes de mexer em qualquer coisa.

O que fazer

Entre no seu servidor (o mesmo acesso SSH que você usou pra instalar), vá até a pasta do projeto e rode:

bash hostgator-setup-kit/update.sh

Pronto. Pode deixar rodando — leva alguns minutos. No fim, você vê ✓ Atualização concluída — app no ar e saudável. Se ele disser que você já está na versão mais recente, é porque não havia nada novo pra baixar; está tudo certo.

O que o comando faz (por baixo)

Confere se há mesmo uma versão nova.
Faz um backup do banco — a rede de segurança, antes de tocar em qualquer coisa.
Baixa o código novo.
Atualiza o banco de dados (inclusive corrigindo sozinho conversas bagunçadas de versões antigas).
Baixa a versão nova do aplicativo e reinicia.
Confere se o CRM voltou no ar.

Coisas normais que você pode ver (não se assuste)

Um monte de linhas com "already exists" / "multiple primary keys" durante a parte do banco: é esperado e inofensivo — são coisas que já existiam. O comando filtra esse ruído e, se estiver tudo certo, mostra ✓ banco atualizado.
Se o banco estiver ocupado com o CRM atendendo, o comando aplica de novo sozinho (até 3 passadas) e mostra na tela o que precisou refazer. Isso é normal, e vale a partir da atualização seguinte à que instalar esta correção (quem executa a atualização é o instalador que já está no servidor).
Se aparecer ⚠ Apareceram avisos no banco que NÃO são os esperados, aí sim vale prestar atenção: o app provavelmente ainda funciona, mas guarde a mensagem. Quando o banco NÃO termina limpo, o fim da saída diz o que fazer, e a resposta depende da causa:
- banco ocupado ou fora de alcance: repita a atualização num horário de pouco movimento, com o comando que a própria tela mostra (bash hostgator-setup-kit/update.sh --to <versão> --force);
- permissão (must be owner, permission denied): repetir não resolve — a conexão do .env não é a dona do banco. Declare SUPABASE_DB_ADMIN_URL e repita;
- qualquer outra coisa: guarde a mensagem e peça ajuda. Só em último caso volte ao estado anterior com o backup: bash hostgator-setup-kit/restore.sh (ele desfaz também o que o CRM gravou depois dele).

Dicas

Quando rodar? Sempre que avisarem que saiu versão nova. Rodar sem ter novidade não faz mal — o comando só diz "já está na última" e sai.
Automático (opcional): dá pra agendar pra toda semana. Rode crontab -e e adicione (troque o caminho pela pasta do seu projeto):
```
0 4 * * 0  cd /caminho/do/deskcommcrm && bash hostgator-setup-kit/update.sh
```
Isso atualiza todo domingo às 4h da manhã, já com backup automático.
Deu algo estranho? Rode bash hostgator-setup-kit/healthcheck.sh pra ver o estado de tudo de uma vez.

3.1 KiB Raw Permalink Blame History