Pedir a un responsable que inicie sesión en GLPI solo para aprobar un ticket es una fricción que cuesta horas de SLA. Quien opera una mesa de servicio conoce la escena: llega el correo de aprobación, el responsable lo lee en el móvil, no tiene la contraseña a mano y el ticket duerme hasta que alguien lo reclama por teléfono.
El problema
Los flujos de aprobación, la validación de solución y las encuestas de satisfacción dependen de una acción de quien casi nunca entra en GLPI: el responsable que autoriza una compra, el cliente externo que confirma que el problema está resuelto, el usuario final que valora la atención. En GLPI nativo, todas esas acciones ocurren dentro de la interfaz autenticada. Para quien no tiene cuenta - o la tiene pero no recuerda la contraseña - eso se convierte en una barrera real.
El resultado es previsible: aprobaciones estancadas, tickets detenidos esperando una respuesta que nunca llega y el equipo perdiendo tiempo en seguimiento manual. La encuesta de satisfacción es el caso extremo: la tasa de respuesta cae cerca de cero cuando exige inicio de sesión, porque el usuario simplemente abandona en la pantalla de autenticación. No es falta de ganas de responder; es un paso más que nadie quiere superar.
Cómo funciona
El módulo Mail Interactions de NexTool añade etiquetas de notificación a GLPI. En el momento en que el correo se encola, el módulo cambia cada etiqueta por una URL única y efímera. El destinatario hace clic, llega a una página pública, confirma la acción y GLPI se actualiza - sin pantalla de inicio de sesión, sin cuenta.
- Aprobar o rechazar validaciones - las etiquetas
##ticket.approve_link##y##ticket.reject_link##se colocan en la plantilla de notificación de validación. El aprobador abre el enlace, opcionalmente escribe una justificación y confirma. - Validar o reabrir la solución -
##ticket.validate_link##cierra el ticket cuando el solicitante confirma que se resolvió;##ticket.reopen_link##lo reabre para nueva atención. - Encuesta de satisfacción con un clic - de
##ticket.satisfaction_link_1##a##ticket.satisfaction_link_10##ya llevan la nota preseleccionada; el usuario hace clic en la puntuación directamente desde el correo y, si quiere, deja un comentario. - Tickets, Cambios y Problemas - las mismas etiquetas existen por tipo de elemento:
##ticket.*##,##change.*##y##problem.*##(en Problema, solo validar y reabrir). - Tokens de un solo uso y con caducidad - cada enlace es válido por un periodo configurable (7 días por defecto) y se invalida en el primer uso, impidiendo clics repetidos o reutilización.
- Justificación obligatoria, cuando tenga sentido - se puede exigir comentario en el rechazo, en la reapertura o en notas de satisfacción por debajo de un umbral, elevando la calidad del registro.
Módulo vs. GLPI nativo
Lo que cambia en la práctica, comparado con el comportamiento estándar de GLPI:
| Acción | GLPI nativo | Con Mail Interactions |
|---|---|---|
| Aprobar / rechazar validación | El aprobador debe iniciar sesión y abrir el ticket | Un clic en el enlace del correo, confirma en la página pública |
| Confirmar / reabrir solución | El solicitante actúa dentro de la interfaz autenticada | Enlace directo en el correo de solución propuesta |
| Encuesta de satisfacción | Respondida en la interfaz o el portal de GLPI | Nota preseleccionada, respuesta con un clic |
| Usuario sin cuenta en GLPI | No puede actuar | Actúa por la página pública, sin consumir un usuario |
| Seguridad del enlace | Sesión autenticada de GLPI | Token de 256 bits de un solo uso, con caducidad y HTTPS |
Un ejemplo real: las etiquetas en la plantilla de notificación
Las etiquetas se colocan en el cuerpo HTML de la plantilla de notificación de validación (Configurar > Notificaciones > Plantillas de notificación). Un fragmento típico del cuerpo:
<!-- Plantilla: evento "Validación de ticket" -->
<p>Hola ##validation.validator##,</p>
<p>El ticket <strong>##ticket.title##</strong> (##ticket.id##)
espera su aprobación.</p>
<p style="text-align:center">
<a href="##ticket.approve_link##"
style="background:#22c55e;color:#fff;padding:12px 20px;border-radius:6px">
Aprobar
</a>
<a href="##ticket.reject_link##"
style="background:#ef4444;color:#fff;padding:12px 20px;border-radius:6px">
Rechazar
</a>
</p>
<p>Los enlaces caducan en 7 días y solo pueden usarse una vez.</p>Cuando se genera el correo, Mail Interactions reemplaza cada etiqueta por una URL tokenizada. Solo a título ilustrativo, el formato es este:
https://soporte.suempresa.com/plugins/nextool/ajax/module_ajax.php
?module=mailinteractions&file=approve.php
&token=Yc7d...token-opaco-de-256-bits...&a=approveEl token no codifica nada del ticket: es un valor aleatorio que solo existe porque se emitió y se guardó en el servidor. No hay forma de falsificarlo, adivinarlo ni reutilizarlo. Los ajustes principales están en la pestaña Configurar del módulo:
# Configurar > NexTool > Módulos > Mail Interactions > Configurar
token_ttl_days = 7 # validez del enlace, en días
force_https_links = 1 # generar siempre URLs https://
require_reject_description = 1 # exigir justificación al rechazar
require_reopen_description = 1 # exigir justificación al reabrir
satisfaction_max_stars = 5 # escala de la encuesta (5 o 10)
satisfaction_require_comment_below = 3 # exigir comentario si la nota < 3Lo que aprendimos en el soporte
Operando GLPI para clientes, el error más común que vemos no es técnico, es de configuración: colocar las etiquetas de aprobación en la plantilla de notificación equivocada. Si pones ##ticket.approve_link## en una plantilla que también se dispara en otros eventos (por ejemplo "Ticket actualizado"), el enlace acaba en correos donde no hay validación pendiente - y el destinatario recibe un enlace que solo lleva a una página de error. Lo correcto es usar esas etiquetas únicamente en la plantilla del evento de validación. Es sencillo, pero explica buena parte del soporte que abrimos sobre "el enlace no funciona".
La segunda lección vino de un detalle de infraestructura. Los appliances de seguridad de correo - Microsoft Safe Links, Mimecast y similares - preabren los enlaces de los mensajes para escanearlos antes de que el usuario haga clic. Si la aprobación se ejecutara en el GET puro del enlace, esos bots "aprobarían" el ticket por su cuenta, generando aprobaciones fantasma. Por eso el módulo nunca actúa en el clic: el enlace abre una página de confirmación y la acción solo se registra en un POST con su propio token de formulario. El bot que hace el pre-fetch ve la página pero no confirma el formulario, así que el token de un solo uso queda intacto. Esa decisión de arquitectura evitó aprobaciones indebidas en un cliente con Office 365 corporativo - un problema que solo aparece en producción, nunca en el entorno de pruebas.
Un detalle fino que conviene conocer: en la validación de solución, cuando la entidad tiene un plazo de cierre configurado (el solvedelay de GLPI), el módulo usa ese plazo como validez del enlace, en lugar del valor por defecto de 7 días. Así el enlace vive exactamente mientras el ticket todavía puede reabrirse - ni más, ni menos.
Cómo activarlo
- Ten el plugin NexTool instalado en tu GLPI 10 u 11.
- Ve a Configurar > NexTool > Módulos.
- Activa Mail Interactions y haz clic en Configurar para definir la validez del token, el HTTPS forzado y las reglas de justificación.
- En Configurar > Notificaciones > Plantillas de notificación, edita la plantilla del evento de validación (o de solución/satisfacción) e incluye las etiquetas deseadas en el cuerpo.
- Dispara una validación de prueba y revisa el correo: los enlaces deben apuntar a
/plugins/nextool/ajax/module_ajax.phpcon un token en la URL.
Para quién es - y cuándo no usarlo
Mail Interactions es adecuado para cualquier organización que use flujos de aprobación en GLPI y sufra lentitud porque los aprobadores no acceden al sistema con frecuencia. Es especialmente valioso para mesas de servicio que atienden a usuarios finales y clientes externos sin cuenta en GLPI - validan soluciones y responden encuestas sin ninguna barrera de acceso.
Cuándo no usarlo: si tu política de seguridad exige que toda aprobación se rastree mediante un inicio de sesión autenticado con MFA (cumplimiento financiero, aprobaciones de alto valor), la página pública no sustituye ese control - en ese caso, mantén la aprobación dentro de la sesión autenticada de GLPI. El módulo elimina fricción; no es un sustituto de una firma electrónica con valor jurídico.
Compatibilidad
- GLPI: 10.0+ y 11.0+
- Plugin: NexTool (módulo Mail Interactions, base 4.3.4 o superior)
- Elementos soportados: Ticket, Cambio y Problema (Problema: solo validar/reabrir)
- Plan: bajo demanda
Siguiente paso
Mail Interactions forma parte de NexTool, un ecosistema de módulos para ampliar GLPI sin personalización de código. Habla con el equipo para una demostración en tu entorno.
Este contenido fue producido con ayuda de inteligencia artificial y revisado por el equipo de Nextool Solutions.
