NexTool Solutions

Las reglas de negocio son el motor de automatización nativo de GLPI: sin una sola línea de código, clasifican, asignan y aplican SLA a cada ticket. Lo que la documentación rara vez explica - y lo que más genera tickets de soporte al mantener parques GLPI de clientes - no es cómo crear una regla, sino el modelo de evaluación que decide qué regla gana cuando dos se cruzan. Esta guía empieza donde la mayoría de los tutoriales termina: el orden, la condición de disparo y el encadenamiento.

El modelo de evaluación que casi nadie lee antes de la primera regla

Toda regla de negocio de ticket es del subtipo RuleTicket y vive en la tabla glpi_rules. Tres columnas gobiernan el comportamiento:

• ranking - el orden de evaluación. El motor lee en orden ascendente, del menor al mayor. La pantalla los muestra de arriba abajo, pero manda el número.
• condition - cuándo se dispara la regla: 1 en la creación, 2 en la actualización, 3 en ambas. Una regla creada solo para 1 nunca se reevalúa cuando el ticket se edita después.
• match - la lógica entre criterios: AND (todos deben cumplirse) o OR (cualquiera de ellos).

El detalle que tumba a la mayoría: las reglas de ticket no se detienen en la primera coincidencia. A diferencia de las reglas del recolector de correo y de la importación de inventario, el motor de RuleTicket recorre TODAS las reglas activas en orden de ranking y usa la salida de una como entrada de la siguiente. Es decir, una regla genérica con ranking mayor (evaluada después) puede sobrescribir la asignación de una regla específica que ya había coincidido antes.

La anatomía real: criterios, acciones y operadores

Cada regla tiene tres bloques. Los criterios están en glpi_rulecriterias, las acciones en glpi_ruleactions:

• Criterio = criteria (el campo) + condition (el operador, numérico) + pattern (el valor esperado).
• Acción = action_type (assign, regex_result, append, fromuser, fromitem) + field (el campo a cambiar) + value.

El operador es un código numérico, no texto - y elegir el equivocado es el fallo silencioso más común. Los valores en GLPI 11:

0  = es (coincidencia exacta)
1  = no es
2  = contiene
3  = no contiene
4  = empieza por
5  = termina por
6  = expresión regular (regex)
7  = regex negada
8  = existe
9  = no existe
11 = bajo (árbol de entidad/categoría)
12 = no bajo

Campos reales que más usas en la acción: _groups_id_assign (grupo técnico), _users_id_assign (técnico), slas_id_ttr (SLA de resolución), itilcategories_id (categoría) y urgency. En criterio, _mailgate identifica el ticket que entró por un recolector de correo específico y _x-priority lee la cabecera de prioridad del correo.

Lista de verificación: una regla que dispara a la primera

1. Define el disparador. ¿Vas a reclasificar en la creación? Usa ONADD (condición 1). ¿Necesitas reaccionar a un cambio de categoría posterior? Marca también la actualización (condición 3).
2. Elige el operador correcto. "Es" (0) exige el título idéntico; para coincidir por fragmento usa "contiene" (2) o regex (6). La mayoría de las reglas de título que "no capturan" usaron "es" donde hacía falta "contiene".
3. Posiciona el ranking. Específica antes, genérica después - pero recuerda que la genérica posterior sobrescribe. Si la genérica no debe tocar lo ya decidido, restringe su criterio.
4. Revisa la entidad. Una regla creada en una entidad hija sin la marca "recursiva" solo se aplica a los tickets de esa entidad - y desaparece para el resto del parque.
5. Prueba en preproducción antes de activar en producción.
6. Valida con Rule Inspector dentro de un ticket real: muestra qué reglas se evaluaron, qué criterios pasaron y cuáles fallaron.

SQL de diagnóstico: lo que ejecutamos cuando "la regla no funciona"

Antes de tocar la interfaz, NexTool vuelca todo el conjunto de reglas de ticket en orden de evaluación. En segundos el ranking cuenta la historia - casi siempre es orden o condición, no un criterio equivocado. Ejecútalo en una réplica de lectura o con cautela en la base de producción:

SELECT r.ranking,
       r.name,
       IF(r.is_active, 'activa', 'INACTIVA') AS estado,
       r.match AS logica,
       CASE r.condition WHEN 1 THEN 'creacion'
                        WHEN 2 THEN 'actualizacion'
                        WHEN 3 THEN 'creacion+actualizacion'
       END AS cuando,
       (SELECT GROUP_CONCAT(
                 CONCAT(c.criteria, ' [op ', c.condition, '] ', c.pattern)
                 ORDER BY c.id SEPARATOR ' | ')
          FROM glpi_rulecriterias c WHERE c.rules_id = r.id) AS criterios,
       (SELECT GROUP_CONCAT(
                 CONCAT(a.action_type, ':', a.field, '=', a.value)
                 ORDER BY a.id SEPARATOR ' | ')
          FROM glpi_ruleactions a WHERE a.rules_id = r.id) AS acciones
FROM glpi_rules r
WHERE r.sub_type = 'RuleTicket'
ORDER BY r.ranking;

Lee de arriba abajo: dos filas que escriben _groups_id_assign significan que gana la de ranking mayor. Una fila con estado = INACTIVA explica la "desaparición" de la regla. cuando = creacion explica por qué editar el ticket no lo redirige.

Matriz de decisión: qué colección de reglas usar

GLPI tiene varias colecciones de reglas, y cada una se comporta de forma distinta. Confundir una con otra es la raíz de muchos "¿por qué esta regla se ejecuta dos veces?":

Para un ticket que llega por correo, ten en cuenta que dos motores se ejecutan en secuencia: primero el del recolector (para en la primera coincidencia), luego el de negocio en el ticket ya creado (los ejecuta todos).

El error de campo más común

En el mantenimiento, el ticket que más abrimos sobre reglas es siempre el mismo: "creé la regla y no captura". En la inmensa mayoría no es el criterio - es el modelo de evaluación. Caso número uno: hay dos reglas que escriben _groups_id_assign, la específica con ranking menor coincide primero, y una regla genérica de ranking mayor, creada meses después "solo para garantizar un grupo por defecto", sobrescribe todo porque el motor encadena la salida. Caso dos: la regla se creó solo con condition = 1 (solo en la creación), así que cuando el agente cambia la categoría después, nada se redirige. Por eso convertimos en estándar de operación ejecutar siempre el SQL de auditoría anterior ANTES de tocar la interfaz: la columna ranking revela el conflicto en segundos, mientras que hacer clic regla por regla en pantalla oculta el orden real de ejecución. Es el tipo de cosa que solo se vuelve obvia cuando operas decenas de entornos y ves repetirse el mismo patrón.

¿Necesitas un GLPI cuya automatización se comporte de forma previsible, sin reglas que se pisen? El soporte NexTool audita y reorganiza tu conjunto de reglas, y el plugin Rule Inspector muestra, dentro de cada ticket, exactamente qué regla decidió qué.

Revisado por el equipo de NexTool Solutions.