NexTool Solutions

Entità e sedi sembrano lo stesso "albero" in GLPI, ma risolvono problemi opposti: l'entità segmenta dati e permessi; la sede è solo un riferimento fisico. Confondere le due - o disegnare la gerarchia di entità dopo che i dati sono già entrati - è l'origine di rilavorazioni che costano giorni. Questa guida mostra come GLPI conserva quegli alberi nel database, un percorso passo passo per la struttura e le trappole che emergono solo mantenendo ambienti multi-entità.

Entità, sede e gruppo: chi fa cosa

Prima di creare qualsiasi nodo, fissi il confine. I tre meccanismi organizzano GLPI, ma lungo assi diversi - e la scelta sbagliata produce fuga di dati o burocrazia inutile.

Regola pratica sul campo: l'entità è un confine di riservatezza, la sede è la mappa fisica dell'asset, il gruppo è la coda di lavoro. Se la domanda è "chi può vedere questo", la risposta è quasi sempre l'entità - una sede non nasconde mai nulla a nessuno.

Come GLPI conserva l'albero delle entità

La schermata Amministrazione > Entità è solo un guscio sopra la tabella glpi_entities. Ogni riga punta al padre tramite la colonna entities_id, conserva il percorso intero in completename e la profondità in level. Due colonne silenziose - sons_cache e ancestors_cache - conservano l'albero pre-calcolato in forma serializzata; è da lì che leggono i filtri di visibilità, non da una JOIN ricorsiva a tempo di query.

-- Albero delle entita: padre, livello e percorso completo
SELECT e.id,
       e.name         AS entita,
       e.completename AS percorso,
       e.level        AS livello,
       p.name         AS entita_padre
FROM   glpi_entities e
LEFT   JOIN glpi_entities p ON p.id = e.entities_id
ORDER  BY e.completename;

Il completename ("Sede > IT > Supporto") è ciò che appare nei selettori e nei report; il level velocizza le query di visibilità. Ricordi questi due nomi: auditi l'albero per completename e GLPI decide l'ambito per level senza scandire l'intera tabella.

Ereditarietà: cosa scende ai figli (e cosa no)

Un'entità figlia non eredita automaticamente i dati della madre - eredita la configurazione contrassegnata come ricorsiva. Categorie, SLA, regole di business, modelli di notifica e sedi portano la coppia (entities_id, is_recursive): per valere su tutto l'albero, l'elemento deve stare sull'entità radice (entities_id = 0) con is_recursive = 1. Creare una categoria dentro un figlio la intrappola lì, e le sorelle non la vedono.

-- Categorie ITIL NON condivise su tutto l'albero
-- (un item globale corretto ha 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);

L'errore comune è creare una categoria ITIL "solo per quel cliente" e poi scoprire che metà dell'operatività non la vede. In manutenzione eseguiamo questo controllo prima di ogni go-live multi-entità: un elemento che dovrebbe essere globale e non è in (0, ricorsivo) è un bug che aspetta il primo ticket.

Passo passo: disegnare la struttura prima dei dati

1. Elenchi i confini di riservatezza reali (chi NON deve vedere cosa). Ogni confine duro diventa un'entità; il resto è una sede o un gruppo.
2. Disegni l'albero su carta con al massimo tre livelli. La profondità impone un pedaggio su ogni selettore e report.
3. Crei le entità dall'interfaccia, dall'alto verso il basso - mai via SQL (veda trappole).
4. Configuri sulla radice ciò che è comune (categorie, SLA, notifiche) spuntando is_recursive; scenda al figlio solo ciò che gli è esclusivo.
5. Solo allora registri utenti, asset e ticket. Spostare dati tra entità dopo è costoso e trascina gli allegati.

Sedi: la gerarchia fisica e il campo che tutti dimenticano

La tabella glpi_locations è gerarchica tramite il proprio locations_id (padre), ma ogni sede appartiene anche a un'entità (entities_id) e ha is_recursive. Una sede creata dentro un figlio non appare nelle altre entità a meno che non sia ricorsiva - lo stesso meccanismo delle categorie. E il valore 0 in locations_id non è nullo: è la sentinella "nessuna sede".

-- Computer senza sede definita, per entita
SELECT e.completename AS entita,
       COUNT(*)       AS senza_sede
FROM   glpi_computers c
JOIN   glpi_entities  e ON e.id = c.entities_id
WHERE  c.locations_id = 0   -- 0 = nessuna (sentinella), non NULL
  AND  c.is_deleted   = 0
GROUP  BY e.completename
ORDER  BY senza_sede DESC;

Un inventario senza sede è lo schema silenzioso che esplode al primo incidente fisico ("in quale rack si trova?"). La query qui sopra diventa un indicatore di igiene della CMDB che seguiamo per entità, non una sorpresa nel cuore della notte.

Trappole sul campo

La peggiore di tutte: creare un'entità direttamente nel database via SQL. La riga entra, ma sons_cache e ancestors_cache della madre non vengono ricalcolati - e poiché i filtri di visibilità leggono da quelle cache, l'entità resta invisibile a getSonsOf(). Il sintomo è crudele: l'entità esiste nella tabella, appare in una SELECT, ma sparisce dai selettori e dall'albero dell'interfaccia. Abbiamo imparato a fatica a non creare mai un'entità con INSERT: è la creazione dallo schermo che ricalcola le cache. Se un import legacy è già entrato via SQL, la correzione è riaprire e salvare ogni entità dall'interfaccia per forzare la ricostruzione dell'albero.

• Trattare l'entità 0 come vuota - l'entità radice ha id = 0, che è un id VALIDO. Codice e integrazioni che testano if (!entities_id) scartano la radice per sbaglio; nei componenti select2 il valore della radice è "" (stringa vuota), mai "0".
• Un documento che sparisce quando sposta un ticket - l'allegato (Document_Item) richiede che il documento stia nella stessa entità del ticket. Spostare il ticket in un'altra entità senza portare il documento rompe l'accesso all'allegato.
• Una sede condivisa senza ricorsione - creare un rack o una stanza dentro un figlio aspettandosi che la sede la veda: senza is_recursive, ogni entità vede solo le proprie sedi.
• Troppe entità - ogni entità moltiplica la configurazione (categorie, SLA, notifiche, assegnazione di profilo per entità). Dieci entità quasi identiche costano dieci volte la manutenzione. Se l'unica differenza tra due aree è un report, usi un gruppo o una sede, non un'entità.

Checklist di struttura organizzativa

1. Mappi i confini di riservatezza prima di toccare GLPI; solo quelli diventano entità.
2. Limiti l'albero delle entità a tre livelli di profondità.
3. Crei le entità dall'interfaccia, mai via SQL.
4. Configuri il comune sulla radice con is_recursive = 1; scenda solo l'esclusivo.
5. Tratti id e locations_id uguali a 0 come un valore valido, non come vuoto.
6. Esegua i controlli dell'elemento globale non condiviso e dell'asset senza sede prima di ogni go-live.

Deve disegnare (o recuperare) una struttura multi-entità senza rilavorazioni, o georeferenziare le Sue sedi su una mappa? NexTool implementa e mantiene ambienti GLPI multi-entità con l'albero rivisto da cima a fondo, e il modulo Geolocation mette le Sue sedi sulla mappa. Parli con il nostro team di implementazione e manutenzione.

Revisionato dal team NexTool Solutions.