El ticket se resolvió, pero la reunión de soporte termina con una duda: ¿en qué grupo quedó detenido? El tiempo total cuenta una parte de la historia. Para mejorar el circuito también necesitás distinguir los compromisos internos, encontrar el procedimiento correcto y saber quién puede ver cada documento.
GLPI 12 cambia varias de esas herramientas de trabajo. Esta guía recorre sus consecuencias para técnicos y administradores, con capturas de GLPI 12.0.0. Si lo que necesitás es decidir cómo actualizar desde GLPI 10, ese recorrido está en la guía sobre su fin de soporte.
En 30 segundos
- Revisá los OLA por grupo si tus tickets pasan por varias especialidades.
- Comprobá quién puede leer cada rama de la base de conocimiento.
- Definí un criterio para los adjuntos internos y la revisión de sesiones.
- Contrastá tableros e integraciones con el trabajo real antes de dar el cambio por validado.
OLA por grupos: separar los compromisos internos
Un SLA expresa un compromiso con quien recibe el servicio. Un OLA ordena compromisos dentro del área que lo presta. Los dos conceptos ya existían; lo nuevo en GLPI 12 es el seguimiento de los OLA por grupo. Podés contrastar esa distinción en la documentación de niveles de servicio y el lanzamiento de GLPI 12.
Pensá en un caso que requiere primero diagnóstico de Infraestructura y después intervención de Aplicaciones. Mirar únicamente el vencimiento final dificulta distinguir qué parte del circuito necesita atención. El seguimiento por grupo da una base más útil para conversar sobre esas esperas.
Qué conviene revisar. Escribí qué significa tomar un caso para cada grupo y con qué horario trabaja. Un objetivo de cuatro horas necesita ese contexto para ser interpretable. Para validar el circuito, prepará una prueba controlada con las asignaciones que efectivamente usan tus técnicos.
Base de conocimiento: el árbol también organiza el acceso
La base de conocimiento pasa de categorías separadas a artículos anidados: un artículo contiene a sus subartículos, y el árbol lateral permite recorrerlos sin salir de la lectura. GLPI 12 también incorpora un editor renovado y herramientas de revisión. El changelog de 12.0.0 detalla la estructura y sus permisos.
Lo importante para administrar esta estructura es la herencia de visibilidad: acceder a un artículo antecesor puede habilitar la lectura de sus descendientes. La raíz tiene un tratamiento especial y no concede automáticamente ese acceso. Las categorías convertidas durante una actualización requieren revisar su visibilidad.
Qué conviene revisar. Separá las instrucciones destinadas al usuario de los procedimientos internos. Por ejemplo, «Cómo pedir acceso» y «Cómo otorgar acceso» pueden hablar del mismo sistema y necesitar públicos distintos. Revisá la rama completa con el perfil destinatario; verla como administrador no alcanza.
Tickets: decidir qué documentos acompañan al solicitante
Un informe de diagnóstico puede servir al técnico y contener detalles que no corresponda compartir con el solicitante. GLPI 12 permite ocultar determinados adjuntos de tickets a ese público. El anuncio oficial también documenta notificaciones para participantes reemplazados y restricciones de criterios de búsqueda por perfil.
Qué conviene revisar. Definí qué clase de documento puede salir al portal y quién toma esa decisión. Después probá el acceso con los perfiles involucrados, incluyendo el enlace al archivo.
Si limitás criterios de búsqueda, verificá que el técnico conserve las consultas necesarias para trabajar. Simplificar una búsqueda y proteger el acceso a los datos son decisiones que hay que revisar por separado; ocultar un criterio no debe usarse como única barrera de confidencialidad.
Seguridad: ver sesiones y volver a confirmar identidad
En Configuración → Seguridad aparecen las sesiones activas, con filtros y acciones de revocación. GLPI 12 también puede pedir una confirmación de identidad antes de entrar a una sección protegida. Son dos controles diferentes documentados entre las novedades de seguridad.
La lista sirve para investigar accesos que necesitan revisión, por ejemplo ante la pérdida de un equipo. Conviene definir quién la consulta, cómo verifica el contexto de un acceso y cuándo escala un hallazgo.
La documentación contempla confirmación con segundo factor y contraseña como alternativa.
Dashboards: empezar por la pregunta que querés responder
La versión amplía filtros —entre ellos entidad, grupos, estados, SLA, técnico y sistema operativo— y paneles de análisis, según el detalle oficial de dashboards. Su utilidad depende de qué estás intentando observar.
Para una reunión de seguimiento, empezá por una pregunta concreta, como qué grupo acumula pendientes o qué categoría requiere más intervención. Después definí población y período. Comparar un mes completo con una semana o dos entidades con cargas distintas puede llevar a conclusiones poco útiles.
Qué conviene revisar. Contrastá un conteo del tablero con su lista de registros y conservá los filtros utilizados.
API e integraciones: elegir la versión de forma explícita
GLPI 12 incorpora la versión 3 de su High-Level API, con esquemas más estrictos. Las versiones anteriores siguen disponibles. El sitio oficial del lanzamiento explica la selección por cabecera GLPI-API-Version o por el endpoint /api.php/v3.0.
Que una API siga disponible no garantiza que cada automatización conserve el resultado esperado. Un conector que lee la base de conocimiento, por ejemplo, necesita contemplar su nueva organización. El changelog también distingue campos de esquemas entre versiones: conviene fijar el contrato que consume cada cliente.
Para una integración empresarial, armá una muestra pequeña de operaciones y compará campos, permisos y errores. Registrá qué versión pide el cliente y qué espera del resultado antes de modificarlo.
Qué conviene comprobar en tu instalación
Usá esta tabla como lista de revisión.
| Funcionalidad | Cambio relevante | Qué revisar en una instalación existente |
|---|---|---|
| OLA | Seguimiento por grupo | Responsables, horarios y transferencias de un caso controlado. |
| Conocimiento | Artículos anidados y herencia de visibilidad | Lectura de cada rama con perfiles internos y de autoservicio. |
| Adjuntos | Documentos ocultos al solicitante | Criterio de publicación y acceso al archivo con cada perfil. |
| Participantes y búsquedas | Avisos y restricciones por perfil | Destinatarios de avisos y consultas necesarias para cada rol. |
| Sesiones | Consulta y revocación centralizadas | Responsables de revisión y procedimiento ante un acceso sospechoso. |
| Dashboards | Más filtros y paneles | Población, período y correspondencia con las listas de registros. |
| API | High-Level API v3 junto a versiones anteriores | Versión solicitada, campos esperados y permisos del conector. |
Por dónde empezar
Si tu mesa de ayuda deriva muchos casos, empezá por los compromisos entre grupos. Si la documentación existe pero cuesta encontrarla, mirá el árbol y sus públicos. Si atendés solicitudes con información interna, revisá adjuntos y sesiones antes de ampliar el uso del portal.
Elegí un circuito, anotá el resultado esperado y comprobalo con los roles que lo usan.
Lectura relacionada: Fin de soporte de GLPI 10: ¿conviene migrar a GLPI 11 o a GLPI 12?. Allí tratamos la elección de versión y la preparación de la actualización.