${{ secrets.ENV_PRODUCTION }} usado direto dentro de um run: substitui o texto
antes do bash rodar - qualquer '$algo' dentro do conteudo do .env.production
(por exemplo em senhas) era interpretado como expansao de variavel de shell.
Com set -u ligado isso quebrou o step "Check required secrets" (variavel nao
definida = erro fatal). Sem set -u, o step "Write .env.production from
secret" teria o mesmo problema de forma silenciosa: qualquer '$algo' dentro
das credenciais reais seria substituido por vazio no arquivo escrito na VM,
corrompendo senha sem nenhum aviso.
Corrige passando o secret via env: e referenciando como variavel de ambiente
normal ($ENV_PRODUCTION) nos dois steps - bash trata o valor como dado opaco,
sem tentar expandir nada dentro dele.
O head fecha o pipe apos ler a primeira linha, o rsync recebe broken pipe e sai
com codigo de erro, e o pipefail propaga isso como falha do step inteiro -
mesmo a versao ja tendo sido impressa com sucesso. Confirmado no primeiro run
real do workflow em producao: Preflight falhou logo depois de imprimir as
versoes, todos os steps seguintes (secrets, validacao, deploy) ficaram
pulados, sem tocar na VM.
Adiciona um step que escreve o .env.production a partir do secret ENV_PRODUCTION
do Gitea Actions (com chmod 600), eliminando o modelo anterior de manter esse
arquivo manualmente na VM sem nenhuma copia de seguranca. Um step anterior falha
cedo e com mensagem clara se o secret nao estiver configurado.
Antes de sincronizar o codigo novo, guarda a versao anterior em
$DEPLOY_PATH.previous, permitindo rollback manual rapido caso o deploy suba
algo quebrado (o node --check so pega erro de sintaxe, nao de logica).
Troca a lista fixa de arquivos validados por node --check (que ja estava
desatualizada, sem cobrir arquivos tocados em mudancas recentes) por uma
varredura em todo .js do projeto.
Cria docs/manualusuario.md: guia pratico "se eu fizer X no SN/GLPI, acontece Y",
pra quem usa os sistemas no dia a dia sem precisar entender a implementacao.
README ganha duas secoes na parte de Producao: onde o .env.production fica e
por que (agora materializado a partir do secret ENV_PRODUCTION do Gitea, nao
mais um arquivo mantido a mao na VM), e o passo a passo de rollback manual
usando o backup .previous que o deploy passa a manter.
Rebaixa para debug uma serie de logs "heartbeat" que disparavam todo ciclo
(a cada 1 minuto) independente de qualquer mudanca real, competindo com os
logs de acao/erro que realmente importam: buscas por watermark, contagem
de tickets pendentes/monitorados, checagens de comentario ja sincronizado,
abertura de conexao GLPI/PostgreSQL, e o resumo de sincronizacao do SN
(que a margem de seguranca de 6h do watermark sempre retorna nao-vazio,
mesmo sem mudanca real de campo).
Corrige tambem um bug real encontrado em teste: no fluxo GLPI -> SN, todo
comentario historico de um ticket era sanitizado e checado contra a API do
SN a cada ciclo antes mesmo de verificar se ja tinha sido sincronizado
(ticket_updates.destiny_id). Em tickets com historico longo isso
significava dezenas de chamadas desnecessarias por minuto. Agora a
checagem local (barata) roda primeiro, e so sanitiza/consulta o SN quando
o comentario realmente ainda nao foi sincronizado.
Corrige tambem o log de configuracao do pool PostgreSQL, que imprimia
"[object Object]" por passar o objeto de config como mensagem em vez de
metadado.
LOG_LEVEL default muda de debug para info em .env.example e
.env.production, unica forma do rebaixamento acima ter efeito pratico.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Consolida os dois controladores legados que decidiam status/fechamento de
forma concorrente (processGlpiClosureController + processStatusController)
em um único processTicketLifecycleController, eliminando a dependência do
campo source_last (mantido só como rastro de auditoria) e a flag
ENABLE_STATUS_SYNC (removida). Isso corrige o bug de reabertura: chamados
reabertos no SN voltavam a ser fechados no GLPI porque a regra de
precedência de finalização do fluxo legado forçava o status do GLPI de
volta pro SN.
Correções de bugs encontrados em teste (Frente 1):
- Constraint UNIQUE em ticket_sync.sn_ticket_id + ON CONFLICT DO NOTHING
na criação do registro, prevenindo duplicação de tickets.
- Fechamento no SN agora é confirmado por leitura ao vivo do status antes
de marcar o ticket como solved/closed, em vez de confiar só no HTTP 200
(a API do SN pode retornar sucesso e silenciosamente ignorar um valor de
estado inválido — descoberto e corrigido também no mandante).
- Nota de encerramento do SN pro GLPI agora é idempotente e criada uma
única vez por ticket.
- Erros de sincronização passam a ter um limite de tentativas
(MAX_ERROR_RETRIES) antes de marcar o ticket como error_permanent,
exigindo intervenção manual em vez de tentar para sempre.
- Chamados criados no GLPI passam a gravar o número do ticket do SN no
campo externalid.
Nova funcionalidade (Frente 2): quando o SN resolve/encerra um chamado por
conta própria antes do GLPI, além da nota informativa no GLPI (agora com o
nome de quem encerrou, buscado ao vivo via resolved_by/closed_by/
sys_updated_by), o próprio SN recebe um aviso de que a Sothis não vai mais
atender aquele chamado e ele é transferido pra fila de TI da CAOA.
Nova funcionalidade (Mandante, regras 19-22): espelhamento opcional e
configurável de status intermediário (Aguardando Atendimento/Em
Atendimento/Em Espera) entre os dois sistemas, controlado pela env
MANDANTE=GLPI|SNOW. Sem essa env configurada, mantém o comportamento atual
(nenhum espelhamento de status intermediário). Nunca afeta os status finais
(resolvido/encerrado/fora de escopo), que continuam regidos pelas regras
fixas de fechamento.
Corrigido também o workflow de deploy (.gitea/workflows/deploy-production.yml),
que ainda validava os controladores antigos (já removidos) e exigia
ENABLE_STATUS_SYNC=true, o que quebraria o próximo deploy em produção.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- Adicionada lógica para detectar quando um ticket é reaberto, verificando se o status do ticket mudou de "Fechado" para "Aberto".
- Isso garante que os comentários sejam processados corretamente mesmo em casos de reabertura de tickets.
- feito ajuste do fluxo GLPI->SN para tratar status 5 (resolve no SN) e status 6 (aviso definitivo e retirada de monitoramento)
- feito ajuste de reabertura SN->GLPI quando ticket estiver solved no GLPI
- feito ajuste de data/hora de comments/worknotes para evitar inversão de data
- feito ajuste de vínculo Ticket Externo no SN com validação de persistência e retry idempotente
- feito ajuste de filtro de journals para ignorar SOTHIS.CAOA e admin.caoa por configuração
- feito inclusão de monitor dedicado de encerramento definitivo (processGlpiClosureController)
- feito atualização de flags de controle (ENABLE_STATUS_SYNC, ENABLE_GLPI_CLOSE_CRON, ENABLE_GLPI_WEBHOOK)
- feito atualização da documentação (README, docs/regrasdenegocio.md, docs/fluxo.md, docs/casosdeuso.md, docs/checklist.md)
- feito ajuste de direção de status para respeitar source_last e evitar reabertura indevida
- feito tratamento de reabertura SN->GLPI após resolução, mantendo bloqueio para fechamento permanente
- feito ajuste de finalização GLPI->SN para propagar resolução/fechamento corretamente
- feito correção de runtime no processStatusController (uso de variável antes da inicialização)
- feito correção para não prender ticket em status transitório de comentários
- feito preservação de ordem cronológica e datas reais de comments/work_notes SN no GLPI
- feito normalização de autor (ex.: email/login para nome amigável)
- feito destaque visual para mensagens automáticas e encerramento no GLPI
- feito sanitização de justificativa na regra de fora de escopo
- feito padronização de variáveis de ambiente e remoção de inconsistências de config
- feito separação de SQL destrutivo para arquivo de manutenção dedicado
- coleta comments e work_notes do SN\n- envia comments como followup e work_notes como tarefa no GLPI\n- usa sys_created_by como author no banco intermediario\n- formata mensagem SN->GLPI com autor no cabecalho\n- aplica regras de resolucao/encerramento SN sem fechar GLPI\n- documenta regras de negocio no README
- Adiciona comentário estilizado no GLPI quando SN marca Resolvido, Encerrado ou Encerrado - Omitido
- Marca Sync como "closed" para remover o chamado da fila de sincronização
- Corrige a direção do bastão da verdade para preservar SNOW -> GLPI quando SN foi a última origem
- normaliza comentarios e logs (ASCII)
- corrige campo no createSyncRecord (glpi_ticket_id)
- remove metodo duplicado updateSourceLast
- corrige uso de ID errado na atualizacao de status/comentarios
- atualiza o README
- Alterado Código para que use o node cron e o gerenciamento seja feito pelo pm2
- Bug que não envia uma atualização para o SN quando um chamo é fechado fora do escopo corrigido
* **Enriquecimento de Dados e Criação de Tickets:**
* Requisições do ServiceNow com descrição vazia agora são enriquecidas buscando dados de variáveis de catálogo (`sc_item_option`), como justificativas e telefones, melhorando a qualidade dos tickets criados no GLPI.
* O `ticketGlpiModel` agora formata descrições em tabelas HTML para melhor legibilidade no GLPI.
* **Refatoração e Novas Funções:**
* O `servicenowService` foi expandido com funções para fechar, atualizar status e adicionar notas de trabalho (`work_notes`) diretamente nos tickets do ServiceNow.
* **Coleta de dados de telefone e ajustes para coletar o Assigment correro
* Water Mark Ajustado para que processo o chamado apenas uma vez.
- **Sincronização Inteligente:** O sistema agora detecta mudanças de estado em qualquer uma das plataformas e propaga a atualização para a outra, respeitando a 'fonte da verdade' (`source_last`).
- **Regra 'Fora do Escopo':** Implementada a regra de negócio para tickets marcados como 'Fora do Escopo' no GLPI (solutiontypes_id = 27). Esses tickets agora são ignorados na sincronização, têm seu status finalizado no GLPI e uma nota informativa é adicionada no ServiceNow.
- **Watermark (Marca d'água):** A coleta de novos tickets do ServiceNow foi otimizada com um sistema de marca d'água, buscando apenas registros atualizados desde a última execução bem-sucedida, o que melhora significativamente a performance.
- **Resiliência:** Adicionado um `processErrorController` que reseta tickets com status de erro, permitindo que sejam reprocessados automaticamente no próximo ciclo.
Testes de fluxo foram realizados com sucesso, validando a criação, resolução (SN <-> GLPI) e a regra 'Fora do Escopo'.
Pendências para a próxima fase:
1. Validar melhor o fluxo de reabertura de chamados em ambas as direções.
2. Garantir que a `work_note` enviada para o ServiceNow na regra 'Fora do Escopo' seja devidamente sanitizada."
