Diagnosticar qué reglas se aplicaron a un ticket de GLPI con Rule Inspector

Deja de depurar reglas de ticket de GLPI abriéndolas una a una. El módulo Rule Inspector de NexTool muestra, dentro del propio ticket, qué reglas se aplicaron, cuáles coincidieron sin ejecutar y cuáles fallaron - con SQL de referencia, comparación con el método manual y exportación CSV para auditoría.

Cuando una regla de ticket en GLPI no hace lo que debería, el diagnóstico suele consumir horas de quien administra el entorno. El módulo Rule Inspector de NexTool invierte ese trabajo: en lugar de abrir las reglas una a una en el gestor, muestra, dentro del propio ticket, qué reglas de ticket se evaluaron, cuáles coincidieron y por qué.

El problema

Las reglas de negocio de ticket están entre las funciones más potentes de GLPI: asignan técnicos, definen categoría y SLA, disparan notificaciones e incluso cierran tickets. Pero cuando algo no funciona - un ticket que llegó sin técnico, una categoría que no se aplicó, un SLA que nunca pegó - el diagnóstico es artesanal. El administrador abre el gestor de reglas, lee criterio por criterio, revisa el orden de ejecución e intenta reconstruir de memoria qué pasó en el instante en que ese ticket entró. En entornos con decenas o cientos de reglas heredadas de años de operación, esto se vuelve una búsqueda del tesoro.

El agravante es que la regla que "no se aplicó" casi siempre se aplicó parcialmente. Coincidió, pero perdió frente a otra de ranking menor que tenía activada la acción "Detener el procesamiento de las reglas" - y a partir de ahí ninguna regla siguiente se ejecuta. Sin una herramienta que muestre la evaluación en el contexto del ticket, ese detalle pasa inadvertido.

Cómo funciona Rule Inspector

Tras instalar y activar el módulo, una pestaña Rules pasa a existir en cada ticket. Desde ella tienes:

  • Consultar reglas - un clic evalúa todas las reglas de ticket activas en la entidad del ticket y muestra cuáles se aplicaron, cuáles coincidieron pero no se ejecutaron y cuáles fallaron en los criterios, con el detalle de cada criterio evaluado.
  • Persistencia por ticket - el resultado queda guardado en el ticket. Al reabrirlo, el botón cambia a "Rehacer consulta", señalando que ya existe una evaluación anterior para comparar.
  • Prueba por ID - en la página independiente del módulo, la pestaña Prueba permite indicar cualquier número de ticket y ver qué reglas son verdaderas para él, sin abrir el ticket.
  • Historial filtrado por entidad - la pestaña Historial lista todas las evaluaciones, restringidas a las entidades que el usuario puede ver. No hay fuga de datos entre entidades.
  • Exportación CSV - el historial sale en CSV con una columna de criterios en el formato criteria | condition | value, lista para auditoría e informe.

La consulta evalúa hasta 1000 reglas por vez, ordenadas por ranking, con un indicador visual cuando se alcanza ese límite - relevante en entornos que acumularon reglas con el tiempo.

Lo que GLPI guarda por debajo

Para entender por qué el diagnóstico manual es penoso, conviene mirar cómo quedan las reglas en la base. La consulta siguiente lista las reglas de ticket activas, por ranking, con sus criterios. Ejecútala en una réplica de lectura o en una ventana de bajo uso:

-- Reglas de ticket activas, por ranking, con sus criterios.
-- criteria y condition son codigos numericos, no texto legible.
SELECT r.ranking,
       r.name              AS regla,
       rc.criteria         AS criterio_cod,
       rc.condition        AS condicion_cod,
       rc.pattern          AS valor
FROM glpi_rules r
JOIN glpi_rulecriterias rc ON rc.rules_id = r.id
WHERE r.sub_type = 'RuleTicket'
  AND r.is_active = 1
ORDER BY r.ranking, rc.id;

El resultado ya explica el dolor: criteria apunta a un campo interno de la regla y condition es un código (por ejemplo, "es igual a", "no es igual a", "expresión regular"). Leer eso a simple vista exige decodificar tabla por tabla y cruzar con el orden de ranking. Rule Inspector entrega esa misma información ya decodificada y, más importante, evaluada contra un ticket real.

Diagnóstico manual vs Rule Inspector

CriterioDiagnóstico manual en GLPIRule Inspector
Dónde investigasGestor de reglas, una a una, o SQL directoPestaña Rules dentro del propio ticket
ContextoSimulas mentalmente los valores del ticketEvalúa contra el ticket real, abierto en pantalla
Lectura de los criteriosCódigos numéricos a decodificarFormato legible criteria | condition | value
Coincidencia vs ejecuciónDifícil distinguir una de otraSepara aplicadas, coincidencia sin ejecución y fallidas
Orden / rankingReconstruir de memoriaEvaluadas por ranking, con el límite señalado
AuditoríaExportación manual, caso a casoExportación CSV e historial filtrado por entidad

Cómo activarlo

  1. Instala el plugin NexTool en tu GLPI.
  2. Accede a Configuración > NexTool > Módulos.
  3. Activa el módulo Rule Inspector.
  4. Sincroniza los permisos desde el panel de NexTool para que los perfiles correctos empiecen a ver la pestaña Rules en el ticket.

Para quién es - y cuándo no usarlo

Rule Inspector es para quien configura y sostiene reglas de ticket: administradores validando una regla nueva, analistas de calidad auditando asignaciones automáticas, gestores de service desk investigando por qué ciertos tickets no reciben categoría o SLA, y equipos que acaban de migrar de versión y necesitan confirmar que las reglas siguen valiendo.

No es la herramienta correcta si tu entorno no usa reglas de ticket, o si la duda está en otro tipo de regla de GLPI - diccionarios de desplegables, reglas de importación de activos, asignación de derechos por LDAP. El módulo se centra en lo que se ejecuta cuando un ticket nace o cambia.

Lo que aprendimos sosteniendo esto

En la sustentación de entornos con muchas reglas, el ticket que "no se asignó" casi nunca es un bug de GLPI: es orden de ranking. Hemos abierto decenas de tickets donde la regla correcta estaba perfecta, pero una regla anterior - ranking menor, por lo tanto evaluada primero - tenía la acción de detener el procesamiento y cortaba la cola antes de llegar a ella. Sin ver la evaluación en el contexto del ticket, el cliente jura que la regla "desapareció", cuando en realidad nunca tuvo la oportunidad de ejecutarse. El segundo patrón recurrente es la entidad: alguien crea la regla en la entidad hija creyendo que vale para todas, pero el ticket entró por otra entidad y la regla simplemente no estaba en el alcance. Rule Inspector acorta ese diagnóstico de horas a segundos porque muestra, para ese ticket específico, qué coincidió y qué se bloqueó - incluso cuando el culpable es una regla de "detener" tres posiciones arriba.

Compatibilidad

  • GLPI: 10.x y 11.x
  • Plan: FREE
  • Plugin: NexTool 3.x+

Rule Inspector forma parte de NexTool, plugin modular para GLPI. Conoce los demás módulos o habla con el equipo para una demostración.


Este contenido fue producido con ayuda de inteligencia artificial y revisado por el equipo de Nextool Solutions.

Preguntas Frecuentes

El módulo Rule Inspector de NexTool evalúa las reglas de ticket activas en la entidad del ticket y muestra, dentro del propio ticket, cuáles se aplicaron, cuáles coincidieron sin ejecutar y cuáles fallaron en los criterios, con el detalle de cada criterio.

En la mayoría de los casos la regla sí coincidió, pero una regla de ranking menor evaluada antes tenía la acción de detener el procesamiento y cortó la cola. Otra causa común es el alcance de entidad. Rule Inspector muestra exactamente qué se bloqueó para ese ticket.

Sí. La pestaña Prueba acepta cualquier ID de ticket y muestra qué reglas son verdaderas para él, y el Historial exporta en CSV con los criterios en formato criteria | condition | value, filtrado por las entidades que el usuario puede ver.

Sí. Rule Inspector es un módulo FREE de NexTool, compatible con GLPI 10.x y 11.x, y requiere el plugin NexTool 3.x o superior.

?Necesitas ayuda?