NexTool Solutions

Un campo personalizzato in GLPI è una decisione di architettura, non un clic. La domanda giusta non è "Fields o nativo?", ma piuttosto: il dato che deve salvare è un attributo di qualcosa che esiste già, oppure è una cosa nuova con vita propria? Questa risposta definisce lo strumento - e il costo che paga negli anni a venire.

Cosa risolve davvero ciascun approccio

Il plugin Fields (mantenuto da Teclib) aggancia campi extra a tipi di elemento che esistono già in GLPI: ticket, computer, utente, contratto, fornitore. Crea un contenitore (un blocco di campi), sceglie su quali tipi appare e aggiunge campi di testo, menu a tendina, data, numero, sì/no e URL. Resta il modo pratico di dire "ogni ticket ha bisogno di un campo Centro di Costo".

Gli oggetti personalizzati di GLPI 11 (asset personalizzati) risolvono un altro problema: creare un nuovo tipo di elemento direttamente nel core, senza plugin. È il sostituto ufficiale del vecchio GenericObject. Definisce "Veicolo", "Sala Riunioni" o "Attrezzatura di Laboratorio" con campi propri, e si comporta come un asset di prima classe: entra nell'inventario, si collega ai ticket, appare nei report.

In sintesi il confine: Fields aggiunge attributi a qualcosa che esiste; un oggetto nativo crea l'entità. Confondere i due è all'origine di quasi ogni grattacapo di manutenzione che compare dopo.

Confronto diretto

Dove vivono i dati (e perché conta)

Ogni contenitore Fields diventa una tabella dedicata nel database, con una riga per elemento e una colonna per campo. Prima di decidere, conviene vedere cosa esiste già nell'ambiente:

-- Dove il plugin Fields salva i valori: una tabella per contenitore,
-- con una riga per elemento e una colonna per campo personalizzato.
SELECT table_name AS tabella_del_contenitore
FROM information_schema.tables
WHERE table_schema = DATABASE()
  AND table_name LIKE 'glpi_plugin_fields_%'
ORDER BY table_name;

-- Definizioni: contenitori (a quali tipi si applicano) e i campi di ciascuno
SELECT c.name AS contenitore, 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;

Questo conta per due motivi operativi. Primo: ogni campo Fields marcato come ricercabile diventa una search option, e il motore di ricerca di GLPI la risolve con un LEFT JOIN aggiuntivo sulla tabella del contenitore. In un cliente con 15 o più contenitori su Ticket, la lista dei ticket inizia a rallentare - non per il volume di dati, ma per il numero di JOIN nel SELECT della ricerca. Secondo: gli oggetti nativi scrivono nello schema del core, quindi escono in export, API e report con lo stesso trattamento dei campi standard, senza tabella parallela da riconciliare.

Il trade-off che emerge nel supporto

Quando gestisce parchi GLPI per i clienti, il costo reale di Fields non è installarlo - è il giorno dell'aggiornamento maggiore. Fields è una dipendenza dura: in una migrazione da GLPI 10 a 11, l'ambiente si avvia solo quando esiste una versione del plugin compatibile con il nuovo core. Abbiamo già trattenuto la finestra di aggiornamento di un cliente aspettando che il plugin pubblicasse la build compatibile, con decine di contenitori in produzione che non potevamo semplicemente spegnere. Un oggetto nativo non ha questo blocco: è il core, sale insieme ad esso.

Due errori comuni che correggiamo spesso. Il primo è modellare un'entità intera come una pila di campi sul ticket - "Contratto di manutenzione" trasformato in 12 campi Fields su Ticket, impossibile da elencare, filtrare o collegare correttamente; lì ci voleva un oggetto (o lo stesso modulo Contratti di GLPI). Il secondo è l'opposto: creare un intero asset personalizzato per quelli che erano due attributi organizzativi su un tipo esistente - complessità di modellazione senza ritorno. E un avviso che diamo sempre: nascondere un campo Fields per profilo è visualizzazione, non sicurezza. Il valore resta nel database e trapela via API, export o ricerca. Se il dato è sensibile, il controllo deve stare altrove.

Verdetto per scenario

Usi Fields quando il dato è un attributo di un tipo che esiste già e non vuole gestire un nuovo tipo: centro di costo e progetto sul ticket, inventario interno sul computer, matricola sull'utente, campi obbligatori o condizionali per categoria di ticket. È veloce, senza downtime e senza migrazione di schema da amministrare.

Usi un oggetto personalizzato nativo quando la "cosa" ha vita propria e la elenca, filtra e collega ai ticket come un elemento: veicoli, sale, asset di laboratorio, apparati che non rientrano in nessun tipo standard. E, obbligatoriamente, quando esce da GenericObject nella migrazione a GLPI 11 - è il percorso di sostituzione ufficiale.

I due convivono. È legittimo avere un asset personalizzato per l'entità e usare comunque Fields per agganciare uno o l'altro attributo organizzativo su ticket che referenziano quell'asset. Ciò che non va bene è usare uno per fare il lavoro dell'altro.

Costo e sforzo

Licenza: entrambi sono gratuiti (GPL). Il costo reale è la manutenzione. Fields addebita in rischio di dipendenza a ogni aggiornamento maggiore e in peso di ricerca man mano che i contenitori crescono. Un oggetto nativo addebita in modellazione iniziale - progetta un tipo, non aggiunge solo un campo - ma dopo non pesa né sull'aggiornamento né su un JOIN parallelo. Come intervallo onesto: aggiungere un campo Fields richiede minuti; modellare un asset personalizzato ben fatto richiede da qualche ora a un giorno, contando campi, profili e integrazione con l'inventario.

In NexTool implementiamo e manteniamo entrambi gli approcci sui GLPI dei clienti. Se sta decidendo tra agganciare più campi o modellare un oggetto - o deve uscire da GenericObject senza rompere lo storico - la nostra consulenza GLPI aiuta a chiudere quella decisione prima che diventi debito tecnico.

Revisionato dal team NexTool Solutions.