GLPI 12 todavía está en desarrollo, pero ya es posible seguir algunos de los cambios que se están trabajando en el repositorio oficial.
No estamos hablando solo de una nueva interfaz o de cambios visuales. El proyecto está pasando por una modernización importante en su estructura, principalmente en el frontend, en la organización de los componentes y en la reducción de dependencias antiguas.
Como todavía no existe una versión estable, todo lo que presentamos en este contenido debe tratarse como un análisis del estado actual del desarrollo. Las funcionalidades, los requisitos e incluso las decisiones técnicas todavía pueden cambiar.
Modernización de la interfaz
Uno de los principales cambios en curso está en el frontend de GLPI.
Hoy, el sistema todavía tiene componentes construidos en diferentes momentos del proyecto. Algunas áreas utilizan páginas PHP tradicionales, otras ya usan Twig, JavaScript moderno y Vue.js.
En GLPI 12, la tendencia es ampliar esa modernización y estandarizar más la interfaz.
Entre los trabajos que ya conseguimos observar están:
mayor utilización de Vue.js;
sustitución gradual de componentes antiguos;
reducción de la dependencia de jQuery;
modernización de los selectores;
revisión de los componentes de carga de archivos;
estandarización de campos y formularios;
mejoras en la navegación;
migración del proceso de compilación a Vite.
Vite debería facilitar el desarrollo y el mantenimiento de los componentes del frontend. Para el usuario final, sin embargo, la principal ganancia debería ser una interfaz más consistente y con comportamientos más estandarizados.
Aun así, esa migración está en desarrollo y no debe considerarse concluida hasta la publicación de la versión estable.
Una interfaz más estandarizada
Quien administra GLPI desde hace algún tiempo sabe que algunos módulos tienen comportamientos diferentes entre sí.
Esto sucede porque partes de la interfaz fueron creadas en épocas diferentes y utilizando tecnologías diferentes.
GLPI 12 debería reducir ese problema mediante la reutilización de componentes.
Esto puede traer mejoras en áreas como:
selección de entidades;
árboles jerárquicos;
campos de formularios;
archivos adjuntos;
menús;
filtros;
mensajes de validación;
casillas de selección;
editores;
búsquedas.
En la práctica, el sistema tiende a volverse más predecible para quien lo utiliza y más simple de mantener para quien desarrolla plugins o integraciones.
Base de Conocimiento
La Base de Conocimiento también está pasando por cambios.
El trabajo involucra el editor de contenido, la gestión de archivos, la navegación entre artículos y la organización de la información.
Esta es un área importante para empresas que utilizan GLPI no solo para tickets, sino también como:
base de procedimientos;
portal interno de documentación;
central de autoservicio;
repositorio de soluciones;
apoyo para equipos de atención.
Como el recurso todavía se está probando, existen ajustes pendientes relacionados con la interfaz, las traducciones, el rendimiento y el comportamiento de las categorías.
Por lo tanto, todavía no es posible afirmar exactamente cómo se entregará la Base de Conocimiento en la versión final.
Activos personalizados
Los activos personalizados fueron una de las principales novedades de GLPI 11.
Este recurso permite crear nuevos tipos de activos sin necesidad de alterar directamente el código fuente de GLPI.
Una empresa puede utilizar esta funcionalidad para controlar, por ejemplo:
máquinas industriales;
equipos médicos;
vehículos;
mobiliario;
herramientas;
equipos de laboratorio;
cualquier otro objeto específico de la operación.
En GLPI 12, la expectativa es que esos activos queden cada vez más integrados con el resto de la plataforma.
Entre los puntos que necesitan seguir evolucionando están:
búsquedas;
permisos;
relaciones;
entidades;
historiales;
formularios;
reglas;
API;
importaciones.
Esta evolución es importante porque permite utilizar GLPI más allá del inventario tradicional de computadoras, monitores, impresoras y equipos de red.
Modernización interna
No todos los cambios serán visibles en la pantalla.
Una parte importante del trabajo de GLPI 12 está sucediendo en la estructura interna del sistema.
Entre los puntos observados están:
refactorización del código PHP;
reducción de código legado;
mayor utilización de plantillas Twig;
creación de componentes reutilizables;
sustitución de bibliotecas antiguas;
mejoras en las pruebas automatizadas;
revisión del frontend;
mejoras en el sistema de traducciones;
evolución de las APIs;
compatibilidad con versiones más recientes de PHP;
revisión de la compatibilidad con las bases de datos soportadas.
Este tipo de cambio no suele llamar tanto la atención como una nueva pantalla, pero es esencial para mantener el proyecto sostenible.
Cuanto menor sea la dependencia de código antiguo, más fácil resulta corregir problemas, implementar nuevas funcionalidades y mantener los plugins compatibles.
La documentación técnica actual de GLPI ya muestra esa transición hacia una arquitectura más modular, basada en controladores, plantillas, APIs y componentes modernos.
APIs e integraciones
Otro punto que necesita seguirse con atención es la evolución de las APIs.
Hoy, muchos entornos utilizan GLPI integrado con:
sistemas de RR. HH.;
ERPs;
herramientas de monitoreo;
soluciones de BI;
Active Directory y LDAP;
plataformas de automatización;
n8n;
sistemas propios;
portales externos;
soluciones de inventario.
Un cambio de versión principal puede alterar endpoints, permisos, campos o formatos de retorno.
Por eso, quien tiene integraciones críticas necesita probar principalmente:
autenticación;
creación y actualización de tickets;
lectura de activos;
búsquedas;
envío de documentos;
relaciones entre objetos;
permisos de los usuarios de API;
retorno de los endpoints.
No es seguro asumir que una integración que funciona en GLPI 11 seguirá funcionando de la misma manera en GLPI 12 sin validación.
Seguridad
La seguridad se sigue trabajando dentro del proyecto.
Ya existen discusiones e implementaciones relacionadas con controles adicionales para operaciones sensibles, revisión de permisos y reautenticación en determinadas acciones.
Aun así, es importante no esperar a GLPI 12 para mantener el entorno seguro.
Las correcciones de seguridad se siguen publicando en las versiones de mantenimiento de GLPI 11. Por lo tanto, los entornos de producción deben permanecer actualizados.
También siguen vigentes las recomendaciones básicas:
no alterar el core;
mantener los plugins actualizados;
eliminar plugins abandonados;
revisar permisos;
proteger archivos de configuración;
utilizar HTTPS;
mantener PHP y la base de datos actualizados;
ejecutar las acciones automáticas correctamente;
revisar usuarios de API;
mantener copia de seguridad de la base de datos y de los archivos.
Compatibilidad de los plugins
Este probablemente será uno de los principales puntos de atención en la migración.
Una nueva versión principal puede alterar clases, métodos, hooks, componentes JavaScript, plantillas y estructuras utilizadas por los plugins.
Antes de actualizar, será necesario validar:
si el plugin tiene una versión compatible;
si el proyecto sigue siendo mantenido;
qué versiones de PHP son compatibles;
si existen cambios en la base de datos;
si hubo cambios en los hooks;
si el frontend del plugin sigue funcionando;
si los permisos siguen correctos;
si las acciones automáticas funcionan;
si existe un proceso oficial de migración.
Los plugins abandonados o que alteran directamente el comportamiento del core representan un riesgo mayor.
Quien tiene muchos plugins instalados debe empezar las pruebas antes del lanzamiento de la versión estable.
Personalizaciones en el core
Si el entorno tiene cambios directamente en los archivos de GLPI, la actualización será más complicada.
Esos cambios pueden sobrescribirse durante el upgrade o simplemente dejar de funcionar.
Lo ideal es que las personalizaciones se hagan utilizando:
plugins;
APIs;
webhooks;
integraciones externas;
recursos oficiales de personalización.
Antes de probar GLPI 12, es importante relevar todos los cambios existentes en el entorno.
Esto incluye:
archivos PHP modificados;
plantillas alteradas;
CSS personalizado;
JavaScript personalizado;
cambios manuales en la base de datos;
triggers;
views;
integraciones;
plugins propios.
Sin ese relevamiento, resulta difícil separar un problema de GLPI de un problema causado por una personalización antigua.
¿GLPI 12 ya se puede utilizar en producción?
No.
La versión actual debe utilizarse solo en laboratorio.
Se puede usar para:
conocer la nueva interfaz;
probar plugins;
validar integraciones;
analizar cambios técnicos;
verificar posibles incompatibilidades;
probar flujos de atención;
preparar al equipo para la migración.
Por estar todavía en desarrollo, pueden ocurrir:
errores;
regresiones;
cambios en la base de datos;
funcionalidades incompletas;
cambios en la interfaz;
incompatibilidad con plugins;
problemas de traducción;
cambios sin aviso previo.
Tampoco recomendamos conectar una versión de desarrollo directamente a la base de datos de producción.
La prueba debe hacerse con una copia aislada de la base de datos y de los archivos.
Estamos siguiendo y probando GLPI 12
En Nextools y en JMBA Soluções, ya estamos siguiendo el desarrollo de GLPI 12 y ejecutando pruebas con las versiones disponibles.
Nuestro objetivo es identificar anticipadamente impactos en:
plugins;
integraciones;
base de datos;
infraestructura;
autenticación;
APIs;
personalizaciones;
proceso de actualización.
Para facilitar estas pruebas, ponemos a disposición una imagen Docker con la versión de desarrollo de GLPI 12.
Para descargar:
docker pull jmbasolucoes/glpi:12-dev
La imagen está destinada exclusivamente a pruebas.
No debe utilizarse en producción.
Con ella, es posible levantar rápidamente un entorno para:
evaluar la interfaz;
probar plugins;
validar LDAP y SSO;
probar integraciones;
analizar el inventario;
revisar formularios;
verificar reglas;
identificar incompatibilidades.
Antes de probar una actualización, utiliza siempre una copia del entorno.
No conectes esta imagen a la base de datos de producción.
Ejemplo de entorno Docker
A continuación hay un ejemplo simple para levantar GLPI 12 con una base de datos exclusiva para laboratorio:
services:
glpi:
image: jmbasolucoes/glpi:12-dev
container_name: glpi-12-dev
restart: unless-stopped
ports:
- "8080:80"
environment:
TZ: America/Sao_Paulo
volumes:
- ./files:/var/lib/glpi
- ./config:/etc/glpi
- ./plugins:/usr/share/glpi/plugins
- ./marketplace:/usr/share/glpi/marketplace
depends_on:
- db
db:
image: mariadb:11.4
container_name: glpi-12-dev-db
restart: unless-stopped
environment:
TZ: America/Sao_Paulo
MARIADB_DATABASE: glpi
MARIADB_USER: glpi
MARIADB_PASSWORD: altere_esta_senha
MARIADB_ROOT_PASSWORD: altere_a_senha_root
volumes:
- ./database:/var/lib/mysql
Para iniciar:
docker compose up -d
Después, accede a:
http://localhost:8080
Este compose es solo un ejemplo de laboratorio y debe ajustarse de acuerdo con el entorno.
Cómo prepararse para GLPI 12
No es necesario esperar la versión estable para empezar la preparación.
El primer paso es organizar el entorno actual.
Actualiza GLPI 11
Antes de pensar en GLPI 12, mantén GLPI 11 actualizado.
Migrar a partir de una versión antigua aumenta la cantidad de cambios y dificulta la identificación de problemas.
Haz un inventario de los plugins
Enumera todos los plugins instalados y registra:
versión;
desarrollador;
finalidad;
criticidad;
estado de mantenimiento;
dependencias;
compatibilidad.
Un plugin instalado y no utilizado debe eliminarse.
Documenta las integraciones
Registra:
endpoint;
método de autenticación;
usuario utilizado;
campos enviados;
campos recibidos;
frecuencia;
dependencias;
tratamiento de errores.
Crea un entorno de homologación
El entorno de pruebas debe reproducir en la mayor medida posible la producción:
PHP;
base de datos;
plugins;
configuraciones;
autenticación;
reglas;
notificaciones;
cron;
integraciones.
Crea un guion de validación
No sirve de nada solo abrir GLPI y verificar si la pantalla cargó.
Es necesario probar los principales procesos:
apertura de tickets;
reglas de asignación;
SLA;
notificaciones;
formularios;
aprobaciones;
tareas;
inventario;
LDAP;
SSO;
acciones automáticas;
API;
informes;
dashboards;
permisos;
entidades.
Qué esperamos realmente de GLPI 12
Por lo que conseguimos observar hasta ahora, GLPI 12 no será solo un cambio de versión.
El proyecto está preparando una base más moderna para los próximos años.
Los principales puntos son:
modernización del frontend;
mayor utilización de Vue.js;
reducción de dependencias antiguas;
estandarización de la interfaz;
evolución de los activos personalizados;
mejoras en la Base de Conocimiento;
revisión de las APIs;
mejoras internas de seguridad;
mantenimiento más simple del código;
mejor estructura para futuras funcionalidades.
Todavía no es posible afirmar qué funcionalidades estarán en la primera versión estable.
Tampoco es posible garantizar que todo lo que aparece hoy en el desarrollo se entregará exactamente de la misma forma.
El momento ahora es de seguir, probar e identificar impactos.
Quien tiene un entorno simple probablemente tendrá un proceso de migración más tranquilo.
Quien tiene muchos plugins, integraciones y cambios propios necesita empezar la validación con antelación.
Para iniciar las pruebas:
docker pull jmbasolucoes/glpi:12-devEn los próximos contenidos, vamos a compartir las pruebas que estamos realizando, las diferencias respecto a GLPI 11 y los problemas encontrados durante esta preparación.
¿Ya estás probando GLPI 12? Cuéntanos qué funcionó, qué se rompió y qué cambios encontraste.
Aviso: este contenido considera el estado de desarrollo de GLPI 12 en julio de 2026. Al tratarse de una versión todavía no estable, las funcionalidades, los requisitos, la estructura y el comportamiento pueden cambiar.
