Novidades do LigarIT

O .env.example passou a ter CACHE_LIMITER=file (9d41985) e o CI copia-o. Sem sobrepor no phpunit.xml, os contadores do throttle ficavam em ficheiro e acumulavam ao longo da suite: o mesmo agente e o mesmo IP esgotavam o limite e 157 testes recebiam 429.

A cloud guardava do agente só o último sinal, IP e versão. Passa a guardar o que lhe acontece em agent_eventos (90 dias, no logs:cleanup):

• POST /api/agent/eventos: o agente manda a sua fila (arranque e motivo da paragem anterior, ligação perdida e recuperada, atualização, licença), idempotente pelo id de cada evento.
• Registo novo ou recusado, versão e IP que mudam, e sem sinal / voltou pelo agentes:vigiar, com o tempo sem sinal.
• O registo grava hostname, plataforma e maquina; o resultado de um job grava duracao_ms.
• /agent-status/{id}: máquina, resumo dos jobs e linha do tempo com os eventos e os jobs falhados ou expirados. Acesso pela regra dos logs.

• Uma conexão com uma palavra-passe de 16 ou mais caracteres dava erro ao gravar. Passam a aceitar-se palavras-passe até aos 200 caracteres que o formulário permite.

• No ecrã de uma Tarefa SQL, as confirmações (apagar e limpar execuções, parar, saltar passo, desativar, eliminar, eliminar agendamento e restaurar versão) passam a aparecer na janela do LigarIT, e não na janela do browser.
• O mesmo para «Eliminar esta conversa?» no chat.

• Quando um passo ainda não tem nenhum teste a seco com sucesso, a barra de progresso do teste a seco passa a estimar pelo tempo das execuções reais desse passo (e o contrário), em vez de mostrar só o tempo decorrido.

• Os botões de cada execução (Detalhe, Apagar, Cancelar pedido, Parar e Saltar passo) passam a ter o mesmo formato, com ícone e uma cor que diz o que fazem.
• A seta do Detalhe roda quando o detalhe está aberto.

O fornecedor de e-mail bloqueia a conta com volume e devoluções («550 5.2.0 Too many sending failures», 15/10). O que os mandava:

• Agente a oscilar: um par «sem sinal / voltou» por queda, a cada supervisor. Depois de uma queda avisada, as seguintes durante 60 min só avisam se o agente estiver calado 10 min.
• Tarefa SQL agendada a oscilar: falha e regresso a cada volta. Um regresso por 30 min; as falhas novas nesse tempo atrasam, não se perdem.
• Resumo de agendamento sem erros: no máximo um por hora por agendamento.
• Novidades: 20 e-mails por minuto em vez de todos de uma vez.
• Destinatários do botão «Executar»: só utilizadores da empresa (e da mãe) e e-mails confirmados da lista de avisos; os outros ficam de fora com um aviso no acompanhamento.

SMS: uma recusa do fornecedor (HTTP < 500 que não 429, ou status false) e um pedido entregue sem resposta a tempo já não se repetem — repetir dava a mesma recusa, ou mandava e pagava o mesmo SMS duas vezes.

• Numa execução que está a correr, aparecem os botões «Parar» e «Saltar passo» (em tarefas com vários passos).
• «Parar» interrompe o passo que corre e não corre os seguintes; «Saltar passo» interrompe-o e passa ao seguinte.
• Num passo com transação, o que o passo tinha feito é revertido. O histórico mostra quem parou e em que lote.
• Nas tarefas que correm pelo agente, o passo é interrompido em até 30 segundos (requer a versão mais recente do agente); nas outras, a execução pára ou salta quando o passo atual acabar.

• Enquanto uma tarefa corre, o ecrã mostra o passo em que vai e uma barra com o tempo decorrido face ao tempo habitual desse passo: se costuma demorar 10 minutos, ao fim de 1 minuto está em 10%.
• O tempo habitual vem das últimas execuções com sucesso do mesmo passo, à parte para o teste a seco.
• Quando um passo demora mais do que o habitual, a barra fica âmbar e avisa; na primeira vez que um passo corre, aparece só o tempo decorrido.

A 15/10 a conta SMTP bloqueou («550 5.2.0 Too many sending failures») e cada e-mail em fila continuou a tentar: 108 tentativas com a conta já bloqueada, cada uma mais uma falha para o fornecedor.

• Com 3 falhas seguidas, o envio pára 15 minutos: os jobs voltam à fila sem tentar (EmailsEmPausa) e, acabada a pausa, só um e-mail tenta.
• Os jobs de e-mail trocam o $tries por maxExceptions + retryUntil, para as voltas à fila não gastarem tentativas.
• O resumo «entre datas» e o da execução manual também contam as falhas e respeitam a pausa.
• SMTP com timeout de 20 s (MAIL_TIMEOUT): era o default_socket_timeout de 60 s, que prendia o worker a cada servidor que não respondia.

• No Teste a seco de uma tarefa com vários passos, a opção «Todos os passos (um de cada vez)» testa cada passo pela ordem, sem gravar nada.
• O teste continua mesmo que um passo falhe, para ver os erros de todos de uma vez; no histórico aparece o resultado de cada passo.
• Cada passo é testado sozinho: o passo 2 não vê o que o 1 fez.

• Na lista de Tarefas SQL, selecione as tarefas e carregue em «Executar» ou «Teste a seco» na barra dos selecionados.
• Antes de correr, vê a lista das tarefas e das conexões onde vão correr. Para executar a sério, basta escrever EXECUTAR uma vez, em vez do nome da base de cada tarefa.
• O teste a seco corre o 1.º passo de cada tarefa e reverte tudo no fim. As tarefas com instruções que o teste não consegue reverter, como COMMIT, só entram se o aceitar.
• No fim, vê o resultado de cada uma: pedida, ou o motivo por que ficou de fora (por exemplo, já estava a correr).

• Na Lista de Mapeamentos, selecione os mapeamentos que quer e carregue em «Executar» na barra dos selecionados: todos são postos a correr para o dia de hoje.
• Os inativos e os PHC→API, que só correm quando o PHC envia dados, ficam de fora; no fim, uma mensagem diz quantos foram postos a correr e quantos foram ignorados.
• O resultado de cada um aparece no histórico de execuções do mapeamento, como sempre.

• Filtro novo «Última execução»: com erro, com sucesso ou nunca correu. Conta a última execução de cada tarefa, por isso uma que falhou antes e já correu bem não aparece como com erro.
• Nas tarefas cuja última execução falhou, o erro aparece na própria lista, por baixo do estado, sem ser preciso abrir cada uma.

Logs: as falhas de envio de e-mail iam para «Sistema», sem ação, e não se encontravam. Passam à categoria nova «Avisos (e-mail e SMS)» — onde caem também os registos do Closum e da E-goi — com as ações email_falhou (cada tentativa), email_nao_enviado (o job desistiu) e emails_a_falhar (crítico), o destinatário mascarado e o erro. O filtro de níveis ganha «Crítico».

Horário (OBS-23): cada telemóvel confirmado da lista da empresa pode receber só num horário (por exemplo, das 09:00 às 18:00, hora de Lisboa, fim incluído, pode passar a meia-noite). Fora dele o aviso perde-se para esse número, sem marca de enviado nem conta no limite, e o registo diz fora_do_horario. A opção só aparece, e só é aceite, num número confirmado.

Foi adicionado um separador Definições com diversas opções, notificações, SMS, aparência, e uso de todos os recursos do plano.

Os agendamentos das Tarefas SQL passam a ter as mesmas opções de frequência do SQL Server Agent:

• Ocorre diária, semanal ou mensalmente, a cada N dias, semanas ou meses. Semanal nos dias que escolher; mensal num dia do mês ou, por exemplo, «na última sexta-feira» ou «no primeiro dia útil».
• Frequência diária: uma vez a uma hora, ou a cada N horas ou minutos entre uma hora de início e uma de fim — por exemplo, de 2 em 2 horas entre as 12:00 e as 23:59.
• Duração: data de início e, se quiser, data de fim.
• Enquanto escolhe, vê o resumo da regra e as próximas cinco execuções.

Os agendamentos que já existiam continuam a correr como antes; ao editá-los, passam ao formato novo.