NexTool Solutions

O pedido mais barato é o que nunca é aberto. Quando o utilizador vê um aviso claro no próprio ecrã do GLPI antes de reportar algo já conhecido, não abre o pedido - e a fila do service desk deixa de encher de duplicados sobre a mesma manutenção ou o mesmo incidente. O plugin News resolve exatamente isto: banners de alerta, comunicado e manutenção dentro da interface, para técnicos e para quem usa o self-service. Na sustentação de parques de clientes, aprendemos que ligar o banner é a parte fácil; o que separa uma comunicação útil de um portal poluído são a segmentação certa, a data de fim e a disciplina de remover o aviso quando ele deixa de valer.

Aviso estático vs notificação ao técnico: não confunda

Antes de instalar qualquer coisa, vale a pena separar dois problemas diferentes. O aviso estático (plugin News, ou os Lembretes Públicos nativos) fala com quem ainda não abriu o pedido - é comunicação preventiva no self-service e no painel. Já a notificação ao técnico (e-mail nativo ou a campainha do Smart Notify) fala com quem já está a tratar do pedido. O erro comum é achar que uma cobre a outra: desligar o e-mail porque há banner, ou colocar um banner à espera de que o técnico seja avisado de um followup. São camadas complementares. O plugin News é a camada de fora - a que evita o pedido nascer.

Instalar e localizar o plugin News

O News é distribuído pelo Marketplace do GLPI e pelo repositório oficial. Depois de o descarregar para plugins/news, instale e ative. Pela linha de comandos, execute como o utilizador do servidor web - a armadilha aqui é usar --allow-superuser ou correr como root, o que grava ficheiros com dono errado e depois parte o cron:

# GLPI 10/11 (CLI) - execute como o utilizador do servidor web, nunca com --allow-superuser:
docker exec --user apache glpi php bin/console glpi:plugin:install news
docker exec --user apache glpi php bin/console glpi:plugin:activate news

# Alternativa pela interface: Configurar > Plugins, botao Instalar e depois Ativar.

Com o plugin ativo, a gestão dos avisos costuma ficar em Ferramentas > Alertas (o rótulo pode variar conforme a versão). Cada alerta tem quatro decisões que importam: o tipo, a mensagem, onde e para quem aparece, e por quanto tempo.

Anatomia de um alerta: os campos que importam

O tipo define a cor e a leitura semântica do banner - o utilizador descodifica a urgência antes de ler o texto. Use a semântica com parcimónia: se tudo é vermelho, nada é urgente.

A visibilidade controla dois eixos: onde o banner aparece (o ecrã central do técnico, o portal self-service, o ecrã de login) e para quem (todos, perfis, grupos ou entidades específicas). É aqui que vive a armadilha que mais causa constrangimento em instalações multi-entidade: criar o alerta na entidade raiz com "recursivo" ligado faz o aviso vazar para o self-service de TODOS os clientes que partilham a mesma instância. Um comunicado de manutenção do Cliente A aparece para o Cliente B. Na sustentação, a regra é delimitar todo o alerta à entidade específica e só usar a raiz recursiva para avisos que valem para toda a base, como uma política de abertura de pedidos.

O período (data de início e fim) é o campo que toda a gente subestima - e é o que mais suja o portal com o tempo.

Modelo pronto: banner de manutenção planeada

A mensagem aceita HTML, por isso dá para padronizar um banner legível em vez de um parágrafo corrido. Este modelo deixa claro o que cai, quando volta e o que o utilizador deve fazer. Copie, ajuste os valores e cole no campo de mensagem:

<strong>Manutencao planeada - Sistema de E-mail</strong><br>
Janela: 15/07/2026, das 22h00 as 02h00 (hora local).<br>
Impacto: o webmail e o envio de mensagens ficarao indisponiveis.<br>
O que fazer: adie envios criticos para depois das 02h00.<br>
<em>Nao e necessario abrir pedido sobre esta indisponibilidade.</em>

Aquela última linha - "não é necessário abrir pedido" - faz mais pela redução da fila do que o banner inteiro. É a instrução explícita que o utilizador procura antes de decidir reportar.

A armadilha do "alerta eterno" e o SQL de higiene

Em toda a instalação que assumimos para sustentar, o padrão repete-se: o portal self-service acumulou seis, oito banners antigos que ninguém expirou. O utilizador aprende a ignorar a faixa inteira - é a cegueira de banner - e quando vem um aviso que importa, ninguém lê. A causa raiz é quase sempre um alerta sem data de fim. Pior ainda é o banner de "estamos cientes da lentidão" que ficou no ar três dias depois de o incidente estar resolvido, a sinalizar um apagão que já acabou e a corroer a confiança no canal. Adotámos uma varredura mensal diretamente na base de dados. Primeiro descubra o schema real (os nomes de coluna variam entre versões do plugin), depois cace os eternos:

-- 1. Localizar a tabela de alertas do plugin News:
SHOW TABLES LIKE 'glpi_plugin_news_%';

-- 2. Conferir os nomes reais das colunas (variam por versao do plugin):
DESCRIBE glpi_plugin_news_alerts;

-- 3. Alertas "eternos" - sem data de fim, a causa raiz da cegueira de banner:
SELECT id, name, type, date_start, date_end
FROM glpi_plugin_news_alerts
WHERE date_end IS NULL OR date_end = '0000-00-00 00:00:00'
ORDER BY date_start;

-- 4. Alertas ainda ativos cuja janela ja passou (esqueceram-se de remover):
SELECT id, name, type, date_end
FROM glpi_plugin_news_alerts
WHERE date_end IS NOT NULL
  AND date_end < NOW()
ORDER BY date_end DESC;

A consulta 4 é a que mais surpreende o cliente: lista o incidente que "já foi resolvido" mas continua no ecrã. Correr isto uma vez por mês mantém o canal com credibilidade - e é barato.

News, Lembretes Públicos ou Smart Notify: qual usar

Nem todo o comunicado precisa de plugin. O GLPI tem Lembretes Públicos nativos, e a NexTool mantém o Smart Notify para o lado dinâmico. Cada um resolve um recorte:

Na prática: use os Lembretes Públicos nativos para um recado simples sem instalar nada; o plugin News quando precisa de banner colorido por tipo, segmentação por ecrã e aviso no ecrã de login; e o Smart Notify para o outro lado da moeda - avisar o técnico, em tempo quase real, de followups, validações e tarefas dentro do próprio GLPI. Não competem: o News evita o pedido nascer, o Smart Notify acelera o pedido que já existe.

Boas práticas de comunicação (da sustentação)

• Toda a mensagem tem data de fim. Sem exceção. Se não sabe quando o aviso expira, não sabe porque o está a publicar.
• Comunique a manutenção com 24h de antecedência e mantenha o banner até ao fim da janela. Em janelas planeadas avisadas com antecedência, vimos a fila de duplicados sobre "sistema em baixo" cair de forma expressiva - trate como um intervalo honesto, não como um número mágico.
• Remova o banner de incidente assim que resolver. Um aviso de apagão no ar depois do apagão é pior do que nenhum aviso.
• Não empilhe banners. Três avisos simultâneos no self-service já é ruído; o quarto ninguém lê.
• Delimite por entidade em instâncias multi-cliente. Recursivo na raiz só para o que vale para toda a gente.
• Cores com significado. Vermelho é incidente ativo, não "leia com atenção".

Na NexTool, tratamos a comunicação no GLPI como parte da operação de sustentação: configuramos os canais certos, definimos a política de expiração dos avisos e cruzamos comunicação estática com notificação dinâmica para o parque do cliente. Se quiser levar isto para além do banner, o módulo Smart Notify cobre o lado do técnico, e a nossa equipa de sustentação ajuda a desenhar o fluxo completo.

Revisto pela equipa NexTool Solutions.