FormCreator fue, durante años, el plugin más instalado de GLPI - y en GLPI 11 deja de existir como plugin. La pregunta ya no es "cuál es mejor", sino una operativa: en qué versión estás y cómo llevas los formularios que ya corren en producción al nuevo módulo nativo sin romper el catálogo de servicios.
Qué cambió de GLPI 10 a GLPI 11
En GLPI 9 y 10, formulario personalizado es sinónimo de FormCreator: un plugin de la comunidad (mantenido por Teclib) que entrega catálogo de servicios, campos condicionales, secciones y generación automática de incidencia a partir de la respuesta. La última línea standalone es la 2.13.x - de ahí en adelante el desarrollo del plugin se detuvo.
En GLPI 11, esa funcionalidad pasó a ser módulo del core: el menú de Formularios, con editor visual, secciones, preguntas condicionales y destinations (lo que el formulario genera - incidencia o cambio). FormCreator standalone no corre en 11. En su lugar solo existe un plugin de transición, el Formcreator Migration Tool (línea 3.0.x), cuya única función es llevar los formularios antiguos al módulo nativo y luego declarar FormCreator en fin de vida (EOL).
Comparativa directa
| Criterio | FormCreator (GLPI 9/10) | Formularios nativos (GLPI 11) |
|---|---|---|
| Naturaleza | Plugin de la comunidad (Teclib) | Módulo del core, sin plugin |
| Compatibilidad | GLPI 9 y 10 (línea 2.13.x) | GLPI 11+ |
| Editor visual | Secciones, preguntas y condiciones | Editor con secciones y condiciones nativas |
| Campos condicionales | Sí, por pregunta y por sección | Sí, condiciones nativas |
| Generación de incidencia | "Target" (incidencia, cambio, problema) | "Destinations" (incidencia, cambio) |
| Dónde guarda las definiciones | Tablas glpi_plugin_formcreator_* | Tablas glpi_forms_* |
| Dónde guarda las respuestas | Tablas del propio plugin | Conjunto de respuestas (answers set) en el core |
| Export/import entre entornos | Limitado al propio plugin | Nativo, en JSON, con reconciliación de dependencias |
| Futuro / mantenimiento | Congelado (EOL tras la migración) | Mantenido por Teclib en el core |
| Migración 10 a 11 | Origen (Migration Tool 3.0.x) | Destino oficial de la migración |
| Costo | Gratuito (GPL) | Incluido en el core |
La migración no es un botón mágico
Existe, sí, una migración oficial - y eso desmiente el mito de que "hay que recrear todo a mano". El camino es asistido: actualiza FormCreator a 2.13.10 o superior aún en GLPI 10, levanta GLPI 11 con el Migration Tool, revisa el volumen en Herramientas > Formcreator EOL Info y ejecuta la migración por línea de comandos.
# 1) Aun en GLPI 10: actualiza FormCreator a la version 2.13.10 o superior.
# 2) Levanta GLPI 11 e instala el "Formcreator Migration Tool" (plugin 3.0.x).
# 3) Revisa el volumen a migrar en el menu Herramientas, item Formcreator EOL Info.
# 4) Ejecuta la migracion por la CLI, como el usuario del servidor web
# (Debian/Ubuntu usa www-data; RHEL/CentOS usa apache):
sudo -u www-data php bin/console migration:formcreator_plugin_to_core
# Orden correcto cuando hay varios plugins heredados en el mismo entorno:
# Generic Objects, luego Fields y por ultimo FormCreator.Antes de ejecutar nada, dimensiona el trabajo. Un inventario rápido en la base de datos te dice cuántos formularios, preguntas y objetivos vas a tener que revisar después - y cuáles son los más pesados:
-- Inventario ANTES de migrar: ejecutalo en la base de GLPI (10, o 11 con el
-- Migration Tool instalado) para dimensionar la revision post-migracion.
SELECT
(SELECT COUNT(*) FROM glpi_plugin_formcreator_forms WHERE is_deleted = 0) AS formularios,
(SELECT COUNT(*) FROM glpi_plugin_formcreator_sections) AS secciones,
(SELECT COUNT(*) FROM glpi_plugin_formcreator_questions) AS preguntas,
(SELECT COUNT(*) FROM glpi_plugin_formcreator_targettickets) AS objetivos_incidencia;
-- Los formularios con mas preguntas son los que mas revision exigen
SELECT f.name AS formulario, COUNT(q.id) AS preguntas
FROM glpi_plugin_formcreator_forms f
LEFT JOIN glpi_plugin_formcreator_sections s
ON s.plugin_formcreator_forms_id = f.id
LEFT JOIN glpi_plugin_formcreator_questions q
ON q.plugin_formcreator_sections_id = s.id
WHERE f.is_deleted = 0
GROUP BY f.id, f.name
ORDER BY preguntas DESC;Lo que la herramienta migra bien es estructura y contenido: secciones, preguntas y tipos de campo. Donde pide revisión humana es en la lógica de enrutamiento - FormCreator usaba el "target ticket" para definir categoría, plantilla, grupo y actores de la incidencia generada; en el nativo eso pasa a ser destinations, y la importación señala las dependencias que faltan en el destino (entidad, categoría) para que las mapees antes de concluir.
El trade-off que aparece en el soporte
Cuando sostienes parques GLPI de clientes, el error más común no es técnico, es de expectativa: alguien ejecuta el comando de migración, los formularios aparecen en el menú nuevo y el equipo da la tarea por terminada. No lo está. Lo que migra es la cáscara; el meollo - qué incidencia se abre, en qué categoría, para qué grupo, con qué plantilla - es justamente lo que exige revisión. Por eso migramos siempre a homologación primero, enviamos una incidencia de prueba por formulario y comparamos el enrutamiento con el comportamiento del FormCreator antiguo, campo por campo.
Dos detalles atrapan a quien lo hace por primera vez. Primero: las tablas glpi_plugin_formcreator_* siguen en la base tras la migración - nada se borra, pasan a ser fuente de lectura/EOL y no desaparecen, así que "se perdió todo" suele ser solo el menú que se movió. Segundo: los formularios nativos reciben IDs (y UUIDs) nuevos, así que cualquier enlace directo, favorito del portal o atajo de self-service que apuntaba a un formulario de FormCreator deja de funcionar y hay que reapuntarlo. Y está el prerrequisito silencioso: si FormCreator está en una versión anterior a la 2.13.10, el Migration Tool simplemente no ve los formularios - actualizar antes de todo es lo que evita la migración "vacía".
Veredicto por escenario
Quédate en FormCreator cuando el entorno es GLPI 9 o 10 y no hay migración a 11 en el horizonte cercano. En esas versiones es la opción madura y sin sustituto para catálogo de servicios y formularios personalizados. Consejo práctico: mantenlo en 2.13.10 o superior aunque no migres ahora - es lo que deja la puerta de la migración abierta cuando llegue el 11.
Usa los formularios nativos cuando estás en GLPI 11 (o vas a migrar). Aquí no hay decisión que tomar: FormCreator standalone no corre en 11, y el módulo nativo es el camino - sin plugin que gestionar en el upgrade, con export/import de formularios entre entornos en JSON (algo que FormCreator nunca hizo de forma nativa) y reconciliación de dependencias en el destino.
Migrando de 10 a 11, usa la herramienta oficial pero trátalo como un proyecto, no como un comando: inventaría los formularios, dimensiona la revisión por la cantidad de preguntas y condiciones, migra a homologación, valida el enrutamiento de cada formulario y solo entonces promueve. Si hay varios plugins heredados, respeta el orden que la propia documentación indica: Generic Objects, luego Fields, luego FormCreator.
Costo y esfuerzo
La licencia no es el eje de la decisión: FormCreator y formularios nativos son gratuitos, y en 11 el nativo ya viene en el core. El costo real es el de la migración y la revisión. La parte automática - ejecutar bin/console - lleva de minutos a algunas decenas de minutos según el volumen. La parte que consume tiempo de gente es validar enrutamiento y rehacer la lógica de destino que no vino 1:1. Como rango honesto: para unos pocos formularios simples, toda la migración cabe en una tarde; para decenas de formularios con muchas condiciones, actores y plantillas, planifica días de revisión en homologación antes de salir a producción.
En NexTool implementamos y sostenemos GLPI para clientes en ambas generaciones y conducimos la migración de FormCreator a los formularios nativos sin tumbar el catálogo de servicios. Si vas a salir de GLPI 10 y no quieres descubrir en producción lo que la migración no trajo, nuestros proyectos de implantación y migración cubren ese camino de punta a punta.
Revisado por el equipo de NexTool Solutions.
