NexTool Solutions

Las entidades y las ubicaciones parecen el mismo "árbol" en GLPI, pero resuelven problemas opuestos: la entidad segmenta datos y permisos; la ubicación es solo una referencia física. Confundir ambas - o diseñar la jerarquía de entidades después de que los datos ya entraron - es el origen de un retrabajo que cuesta días. Esta guía muestra cómo GLPI guarda esos árboles en la base de datos, un paso a paso para la estructura y las trampas que solo aparecen manteniendo entornos multientidad.

Entidad, ubicación y grupo: quién hace qué

Antes de crear cualquier nodo, fija la frontera. Los tres mecanismos organizan GLPI, pero por ejes distintos - y la elección equivocada genera fuga de datos o burocracia inútil.

Regla práctica de campo: la entidad es una frontera de confidencialidad, la ubicación es el mapa físico del activo, el grupo es la cola de trabajo. Si la pregunta es "quién puede ver esto", la respuesta casi siempre es entidad - una ubicación nunca oculta nada a nadie.

Cómo guarda GLPI el árbol de entidades

La pantalla Administración > Entidades es solo una capa sobre la tabla glpi_entities. Cada fila apunta a su padre por la columna entities_id, guarda la ruta completa en completename y la profundidad en level. Dos columnas silenciosas - sons_cache y ancestors_cache - guardan el árbol precalculado en forma serializada; de ahí leen los filtros de visibilidad, no de un JOIN recursivo en tiempo de consulta.

-- Arbol de entidades: padre, nivel y ruta completa
SELECT e.id,
       e.name         AS entidad,
       e.completename AS ruta,
       e.level        AS nivel,
       p.name         AS entidad_padre
FROM   glpi_entities e
LEFT   JOIN glpi_entities p ON p.id = e.entities_id
ORDER  BY e.completename;

El completename ("Central > TI > Soporte") es lo que aparece en los selectores e informes; el level acelera las consultas de visibilidad. Recuerda esos dos nombres: auditas el árbol por completename y GLPI decide el alcance por level sin recorrer toda la tabla.

Herencia: qué desciende a las hijas (y qué no)

Una entidad hija no hereda datos de la madre automáticamente - hereda configuración marcada como recursiva. Categorías, SLA, reglas de negocio, plantillas de notificación y ubicaciones llevan el par (entities_id, is_recursive): para valer en todo el árbol, el ítem debe estar en la entidad raíz (entities_id = 0) con is_recursive = 1. Crear una categoría dentro de una hija la atrapa allí, y las hermanas no la ven.

-- Categorias ITIL que NO estan compartidas para todo el arbol
-- (un item global correcto tiene entities_id = 0 e is_recursive = 1)
SELECT id, name, entities_id, is_recursive
FROM   glpi_itilcategories
WHERE  NOT (entities_id = 0 AND is_recursive = 1);

El error común es crear una categoría ITIL "solo para ese cliente" y luego descubrir que la mitad de la operación no la ve. En el mantenimiento ejecutamos esta comprobación antes de cualquier salida a producción multientidad: un ítem que debería ser global y no está en (0, recursivo) es un bug esperando el primer ticket.

Paso a paso: diseñar la estructura antes que los datos

1. Enumera las fronteras de confidencialidad reales (quién NO debe ver qué). Cada frontera dura se vuelve una entidad; el resto es ubicación o grupo.
2. Dibuja el árbol en papel con como máximo tres niveles. La profundidad cobra peaje en cada selector e informe.
3. Crea las entidades por la interfaz, de arriba hacia abajo - nunca por SQL (ver trampas).
4. Configura en la raíz lo común (categorías, SLA, notificaciones) marcando is_recursive; baja a la hija solo lo que sea exclusivo de ella.
5. Solo entonces registra usuarios, activos y tickets. Mover datos entre entidades después es caro y arrastra adjuntos.

Ubicaciones: la jerarquía física y el campo que todos olvidan

La tabla glpi_locations es jerárquica por su propio locations_id (padre), pero cada ubicación también pertenece a una entidad (entities_id) y tiene is_recursive. Una ubicación creada dentro de una hija no aparece en las otras entidades a menos que sea recursiva - el mismo mecanismo de las categorías. Y el valor 0 en locations_id no es nulo: es el centinela "ninguna ubicación".

-- Computadoras sin ubicacion definida, por entidad
SELECT e.completename AS entidad,
       COUNT(*)       AS sin_ubicacion
FROM   glpi_computers c
JOIN   glpi_entities  e ON e.id = c.entities_id
WHERE  c.locations_id = 0   -- 0 = ninguna (centinela), no NULL
  AND  c.is_deleted   = 0
GROUP  BY e.completename
ORDER  BY sin_ubicacion DESC;

Un inventario sin ubicación es el patrón silencioso que explota en el primer incidente físico ("¿en qué rack está?"). La consulta anterior se convierte en un indicador de higiene de CMDB que seguimos por entidad, no en una sorpresa a mitad de la madrugada.

Trampas de campo

La peor de todas: crear una entidad directamente en la base de datos por SQL. La fila entra, pero sons_cache y ancestors_cache de la madre no se recalculan - y como los filtros de visibilidad leen de esos cachés, la entidad queda invisible para getSonsOf(). El síntoma es cruel: la entidad existe en la tabla, aparece en un SELECT, pero desaparece de los selectores y del árbol de la interfaz. Aprendimos a la fuerza a nunca crear una entidad por INSERT: es la creación por la pantalla la que recalcula los cachés. Si una importación heredada ya entró por SQL, la corrección es reabrir y guardar cada entidad por la interfaz para forzar la reconstrucción del árbol.

• Tratar la entidad 0 como vacía - la entidad raíz tiene id = 0, que es un id VÁLIDO. El código y las integraciones que prueban if (!entities_id) descartan la raíz sin querer; en componentes select2 el valor de la raíz es "" (cadena vacía), nunca "0".
• Un documento que desaparece al mover el ticket - el adjunto (Document_Item) exige que el documento esté en la misma entidad que el ticket. Mover el ticket a otra entidad sin llevar el documento rompe el acceso al adjunto.
• Una ubicación compartida sin recursión - crear un rack o sala dentro de una hija esperando que la central lo vea: sin is_recursive, cada entidad solo ve sus propias ubicaciones.
• Demasiadas entidades - cada entidad multiplica la configuración (categorías, SLA, notificaciones, asignación de perfil por entidad). Diez entidades casi idénticas cuestan diez veces el mantenimiento. Si la única diferencia entre dos áreas es un informe, usa un grupo o una ubicación, no una entidad.

Checklist de estructura organizativa

1. Mapea las fronteras de confidencialidad antes de tocar GLPI; solo esas se vuelven entidades.
2. Limita el árbol de entidades a tres niveles de profundidad.
3. Crea entidades por la interfaz, nunca por SQL.
4. Configura lo común en la raíz con is_recursive = 1; baja solo lo exclusivo.
5. Trata id y locations_id iguales a 0 como un valor válido, no como vacío.
6. Ejecuta las comprobaciones de ítem global no compartido y de activo sin ubicación antes de cada salida a producción.

¿Necesitas diseñar (o rescatar) una estructura multientidad sin retrabajo, o georreferenciar tus ubicaciones en un mapa? NexTool implanta y mantiene entornos GLPI multientidad con el árbol revisado de punta a punta, y el módulo Geolocation pone tus ubicaciones en el mapa. Habla con nuestro equipo de implantación y mantenimiento.

Revisado por el equipo de NexTool Solutions.