NexTool Solutions

Un campo personalizado en GLPI es una decisión de arquitectura, no un clic. La pregunta correcta no es "¿Fields o nativo?", sino: el dato que necesitas guardar ¿es un atributo de algo que ya existe, o es una cosa nueva con vida propia? Esa respuesta define la herramienta - y el costo que pagas durante los próximos años.

Qué resuelve realmente cada enfoque

El plugin Fields (mantenido por Teclib) cuelga campos extra en tipos de elemento que ya existen en GLPI: incidencia, ordenador, usuario, contrato, proveedor. Creas un contenedor (un bloque de campos), eliges en qué tipos aparece y agregas campos de texto, desplegable, fecha, número, sí/no y URL. Sigue siendo la forma práctica de decir "toda incidencia necesita un campo Centro de Costo".

Los objetos personalizados de GLPI 11 (activos personalizados) resuelven otro problema: crear un tipo de elemento nuevo directamente en el core, sin plugin. Es el sustituto oficial del antiguo GenericObject. Defines "Vehículo", "Sala de Reuniones" o "Equipo de Laboratorio" con campos propios, y pasa a comportarse como un activo de primera clase: entra en inventario, se vincula a incidencias, aparece en informes.

Resumiendo la frontera: Fields agrega atributos a algo que existe; un objeto nativo crea la entidad. Confundir ambos es el origen de casi todo dolor de mantenimiento que aparece después.

Comparativa directa

Dónde viven los datos (y por qué importa)

Cada contenedor de Fields se convierte en una tabla dedicada en la base de datos, con una fila por elemento y una columna por campo. Antes de decidir, conviene ver lo que ya existe en el entorno:

-- Donde el plugin Fields guarda los valores: una tabla por contenedor,
-- con una fila por elemento y una columna por campo personalizado.
SELECT table_name AS tabla_de_contenedor
FROM information_schema.tables
WHERE table_schema = DATABASE()
  AND table_name LIKE 'glpi_plugin_fields_%'
ORDER BY table_name;

-- Definiciones: contenedores (a que tipos se aplican) y los campos de cada uno
SELECT c.name AS contenedor, c.itemtypes, f.name AS campo, f.type
FROM glpi_plugin_fields_containers c
JOIN glpi_plugin_fields_fields f
  ON f.plugin_fields_containers_id = c.id
ORDER BY c.name, f.ranking;

Esto importa por dos motivos operativos. Primero: cada campo de Fields marcado como buscable se convierte en una search option, y el motor de búsqueda de GLPI lo resuelve con un LEFT JOIN adicional sobre la tabla del contenedor. En un cliente con 15 o más contenedores en Ticket, la lista de incidencias empieza a ir lenta - no por el volumen de datos, sino por la cantidad de JOINs en el SELECT de la búsqueda. Segundo: los objetos nativos escriben en el schema del core, así que salen en export, API e informe con el mismo trato que los campos estándar, sin tabla paralela que reconciliar.

El trade-off que aparece en el soporte

Cuando sostienes parques GLPI de clientes, el costo real de Fields no es instalarlo - es el día de la actualización mayor. Fields es una dependencia dura: en una migración de GLPI 10 a 11, el entorno solo levanta cuando existe una versión del plugin compatible con el core nuevo. Ya hemos retenido la ventana de actualización de un cliente esperando que el plugin publicara la build compatible, con decenas de contenedores en producción que no podíamos simplemente apagar. Un objeto nativo no tiene esa barrera: es el core, sube con él.

Dos errores comunes que corregimos con frecuencia. El primero es modelar una entidad entera como una pila de campos en la incidencia - "Contrato de mantenimiento" convertido en 12 campos Fields en Ticket, imposible de listar, filtrar o relacionar bien; ahí cabía un objeto (o el propio módulo de Contratos de GLPI). El segundo es el opuesto: crear un activo personalizado entero para lo que eran dos atributos organizativos en un tipo existente - complejidad de modelado sin retorno. Y una advertencia que siempre damos: ocultar un campo de Fields por perfil es visual, no seguridad. El valor sigue en la base de datos y se filtra por API, export o búsqueda. Si el dato es sensible, el control tiene que estar en otro lado.

Veredicto por escenario

Usa Fields cuando el dato es un atributo de un tipo que ya existe y no quieres gestionar un tipo nuevo: centro de costo y proyecto en la incidencia, patrimonio interno en el ordenador, matrícula en el usuario, campos obligatorios o condicionales por categoría de incidencia. Es rápido, sin downtime y sin migración de schema que administrar.

Usa un objeto personalizado nativo cuando la "cosa" tiene vida propia y vas a listarla, filtrarla y vincularla a incidencias como un elemento: vehículos, salas, activos de laboratorio, equipos que no encajan en ningún tipo estándar. Y, obligatoriamente, cuando salgas de GenericObject en la migración a GLPI 11 - es el camino de sustitución oficial.

Los dos conviven. Es legítimo tener un activo personalizado para la entidad y aun así usar Fields para colgar uno u otro atributo organizativo en incidencias que referencian ese activo. Lo que no vale es usar uno para hacer el trabajo del otro.

Costo y esfuerzo

Licencia: ambos son gratuitos (GPL). El costo real es de mantenimiento. Fields cobra en riesgo de dependencia en cada actualización mayor y en peso de búsqueda a medida que los contenedores crecen. Un objeto nativo cobra en modelado inicial - diseñas un tipo, no solo agregas un campo - pero después no pesa en actualización ni en JOIN paralelo. Como rango honesto: agregar un campo Fields lleva minutos; modelar un activo personalizado bien hecho lleva de unas horas a un día, contando campos, perfiles e integración con inventario.

En NexTool implementamos y sostenemos ambos enfoques en el GLPI de clientes. Si estás decidiendo entre colgar más campos o modelar un objeto - o necesitas salir de GenericObject sin romper el histórico - nuestra consultoría de GLPI ayuda a cerrar esa decisión antes de que se vuelva deuda técnica.

Revisado por el equipo de NexTool Solutions.