El ticket más barato es el que nunca se abre. Cuando el usuario ve un aviso claro en la propia pantalla de GLPI antes de reportar algo ya conocido, no abre el ticket - y la cola del service desk deja de llenarse de duplicados sobre el mismo mantenimiento o el mismo incidente. El plugin News resuelve justo esto: banners de alerta, comunicado y mantenimiento dentro de la interfaz, para técnicos y para quien usa el self-service. En la operación de mantenimiento de entornos de clientes aprendimos que encender el banner es la parte fácil; lo que separa una comunicación útil de un portal saturado son la segmentación correcta, la fecha de fin y la disciplina de retirar el aviso cuando deja de aplicar.
Aviso estático vs notificación al técnico: no los confundas
Antes de instalar nada, conviene separar dos problemas distintos. El aviso estático (plugin News, o los Recordatorios Públicos nativos) habla con quien todavía no ha abierto el ticket - es comunicación preventiva en el self-service y en el panel. La notificación al técnico (correo nativo o la campana de Smart Notify) habla con quien ya está atendiendo el ticket. El error común es creer que una cubre a la otra: apagar el correo porque hay banner, o poner un banner esperando que el técnico se entere de un seguimiento. Son capas complementarias. El plugin News es la capa de fuera - la que evita que el ticket nazca.
Instalar y localizar el plugin News
News se distribuye por el Marketplace de GLPI y por el repositorio oficial. Tras descargarlo en plugins/news, instálalo y actívalo. Por línea de comandos, ejecútalo como el usuario del servidor web - la trampa aquí es usar --allow-superuser o correr como root, lo que graba archivos con dueño equivocado y luego rompe el cron:
# GLPI 10/11 (CLI) - ejecuta como el usuario del servidor web, nunca con --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 por interfaz: Configurar > Plugins, boton Instalar y luego Activar.Con el plugin activo, la gestión de los avisos suele estar en Herramientas > Alertas (la etiqueta puede variar según la versión). Cada alerta tiene cuatro decisiones que importan: el tipo, el mensaje, dónde y para quién aparece, y por cuánto tiempo.
Anatomía de una alerta: los campos que importan
El tipo define el color y la lectura semántica del banner - el usuario decodifica la urgencia antes de leer el texto. Usa la semántica con moderación: si todo es rojo, nada es urgente.
| Tipo | Color / semántica | Cuándo usar | Ejemplo |
|---|---|---|---|
| Información | Azul - neutro | Comunicado general, novedad | "Nueva versión de GLPI disponible" |
| Advertencia | Amarillo - atención | Algo a tener en cuenta, sin urgencia | "Incluye el número de activo al abrir un ticket" |
| Problema | Rojo - crítico | Incidente activo en curso | "Somos conscientes de la lentitud del correo" |
| Mantenimiento | Destacado - programado | Ventana planificada con hora fijada | "Sistema X en mantenimiento el 15/07, 22h-2h" |
La visibilidad controla dos ejes: dónde aparece el banner (la pantalla central del técnico, el portal self-service, la pantalla de login) y para quién (todos, perfiles, grupos o entidades específicas). Aquí vive la trampa que más incomoda en instalaciones multi-entidad: crear la alerta en la entidad raíz con "recursivo" activado hace que el aviso se filtre al self-service de TODOS los clientes que comparten la misma instancia. Un comunicado de mantenimiento del Cliente A aparece para el Cliente B. En la operación de mantenimiento, la regla es acotar cada alerta a la entidad específica y usar la raíz recursiva solo para avisos que aplican a toda la base, como una política de apertura de tickets.
El período (fecha de inicio y fin) es el campo que todos subestiman - y el que más ensucia el portal con el tiempo.
Plantilla lista: banner de mantenimiento programado
El mensaje acepta HTML, así que puedes estandarizar un banner legible en vez de un párrafo corrido. Esta plantilla deja claro qué se cae, cuándo vuelve y qué debe hacer el usuario. Cópiala, ajusta los valores y pégala en el campo de mensaje:
<strong>Mantenimiento programado - Sistema de Correo</strong><br>
Ventana: 15/07/2026, de 22h00 a 02h00 (hora local).<br>
Impacto: el webmail y el envio de mensajes estaran no disponibles.<br>
Que hacer: pospon los envios criticos hasta despues de las 02h00.<br>
<em>No es necesario abrir un ticket sobre esta indisponibilidad.</em>Esa última línea - "no es necesario abrir un ticket" - hace más por reducir la cola que todo el banner. Es la instrucción explícita que el usuario busca antes de decidir reportar.
La trampa de la "alerta eterna" y el SQL de higiene
En toda instalación que asumimos para mantener, el patrón se repite: el portal self-service acumuló seis u ocho banners viejos que nadie caducó. El usuario aprende a ignorar la franja entera - es la ceguera de banner - y cuando llega un aviso que importa, nadie lo lee. La causa raíz casi siempre es una alerta sin fecha de fin. Peor aún es el banner de "somos conscientes de la lentitud" que quedó tres días después de resolver el incidente, señalando un apagón que ya terminó y erosionando la confianza en el canal. Adoptamos un barrido mensual directo en la base de datos. Primero descubre el esquema real (los nombres de columna varían entre versiones del plugin), luego caza los eternos:
-- 1. Localizar la tabla de alertas del plugin News:
SHOW TABLES LIKE 'glpi_plugin_news_%';
-- 2. Comprobar los nombres reales de las columnas (varian por version del plugin):
DESCRIBE glpi_plugin_news_alerts;
-- 3. Alertas "eternas" - sin fecha de fin, la causa raiz de la ceguera 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 aun activas cuya ventana ya paso (olvidaron retirarla):
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;La consulta 4 es la que más sorprende al cliente: lista el incidente que "ya se resolvió" pero sigue en pantalla. Ejecutar esto una vez al mes mantiene el canal creíble - y es barato.
News, Recordatorios Públicos o Smart Notify: cuál usar
No todo comunicado necesita un plugin. GLPI tiene Recordatorios Públicos nativos, y NexTool mantiene Smart Notify para el lado dinámico. Cada uno resuelve un recorte:
| Criterio | Recordatorios Públicos (nativo) | Plugin News | Smart Notify (NexTool) |
|---|---|---|---|
| Naturaleza | Texto/aviso simple | Banner estático por tipo | Notificación dinámica (campana) |
| Público objetivo | Quien aún no ha abierto | Quien aún no ha abierto | Técnico en sesión |
| Dónde aparece | Área de planificación / central | Central, self-service y login | Campana en la navbar de GLPI |
| Segmentación | Perfil / entidad | Tipo, pantalla, perfil, grupo, entidad | Por evento y por técnico |
| Color por gravedad | No | Sí (info / advertencia / problema) | Sonido por prioridad |
| Requiere instalar plugin | No (nativo) | Sí | Sí (módulo NexTool) |
| Mejor para | Recado rápido sin plugin | Mantenimiento e incidente en self-service | Avisar al técnico de lo que cambió |
En la práctica: usa los Recordatorios Públicos nativos para un recado simple sin instalar nada; el plugin News cuando necesitas banner coloreado por tipo, segmentación por pantalla y aviso en la pantalla de login; y Smart Notify para la otra cara de la moneda - avisar al técnico, en tiempo casi real, de seguimientos, validaciones y tareas dentro del propio GLPI. No compiten: News evita que el ticket nazca, Smart Notify acelera el ticket que ya existe.
Buenas prácticas de comunicación (de la operación de mantenimiento)
- Todo mensaje tiene fecha de fin. Sin excepción. Si no sabes cuándo caduca el aviso, no sabes por qué lo estás publicando.
- Comunica el mantenimiento con 24h de antelación y mantén el banner hasta el fin de la ventana. En ventanas planificadas avisadas con antelación vimos caer de forma notable la cola de duplicados sobre "sistema caído" - trátalo como un rango honesto, no como un número mágico.
- Retira el banner de incidente en cuanto se resuelva. Un aviso de apagón que sigue tras el apagón es peor que ningún aviso.
- No apiles banners. Tres avisos simultáneos en el self-service ya es ruido; el cuarto no lo lee nadie.
- Acota por entidad en instancias multi-cliente. Recursivo en la raíz solo para lo que aplica a todos.
- Colores con significado. Rojo es incidente activo, no "lee con atención".
En NexTool tratamos la comunicación en GLPI como parte de la operación de mantenimiento: configuramos los canales correctos, definimos la política de caducidad de los avisos y cruzamos comunicación estática con notificación dinámica para el parque del cliente. Si quieres llevar esto más allá del banner, el módulo Smart Notify cubre el lado del técnico, y nuestro equipo de mantenimiento ayuda a diseñar el flujo completo.
Revisado por el equipo de NexTool Solutions.
