GLPI 12 è ancora in fase di sviluppo, ma è già possibile seguire alcuni dei cambiamenti su cui si sta lavorando nel repository ufficiale.
Non stiamo parlando solo di una nuova interfaccia o di modifiche visive. Il progetto sta attraversando un'importante modernizzazione della sua struttura, soprattutto nel frontend, nell'organizzazione dei componenti e nella riduzione delle dipendenze obsolete.
Poiché non esiste ancora una versione stabile, tutto ciò che presentiamo in questo contenuto deve essere considerato come un'analisi dello stato attuale dello sviluppo. Funzionalità, requisiti e persino decisioni tecniche possono ancora cambiare.
Modernizzazione dell'interfaccia
Uno dei principali cambiamenti in corso riguarda il frontend di GLPI.
Oggi il sistema possiede ancora componenti costruiti in momenti diversi del progetto. Alcune aree utilizzano pagine PHP tradizionali, altre già usano Twig, JavaScript moderno e Vue.js.
In GLPI 12, la tendenza è ampliare questa modernizzazione e standardizzare maggiormente l'interfaccia.
Tra i lavori che siamo già riusciti a osservare ci sono:
maggiore utilizzo di Vue.js;
sostituzione graduale dei componenti obsoleti;
riduzione della dipendenza da jQuery;
modernizzazione dei selettori;
revisione dei componenti di upload;
standardizzazione di campi e moduli;
miglioramenti nella navigazione;
migrazione del processo di compilazione a Vite.
Vite dovrebbe facilitare lo sviluppo e la manutenzione dei componenti del frontend. Per l'utente finale, tuttavia, il principale vantaggio dovrebbe essere un'interfaccia più coerente e con comportamenti più standardizzati.
Ciononostante, questa migrazione è ancora in fase di sviluppo e non deve essere considerata conclusa fino alla pubblicazione della versione stabile.
Un'interfaccia più standardizzata
Chi amministra GLPI da tempo sa che alcuni moduli hanno comportamenti diversi tra loro.
Questo accade perché alcune parti dell'interfaccia sono state create in epoche diverse e utilizzando tecnologie diverse.
GLPI 12 dovrebbe ridurre questo problema attraverso il riutilizzo dei componenti.
Questo può portare miglioramenti in aree come:
selezione delle entità;
alberi gerarchici;
campi dei moduli;
allegati;
menu;
filtri;
messaggi di validazione;
caselle di selezione;
editor;
ricerche.
In pratica, il sistema tende a diventare più prevedibile per chi lo utilizza e più semplice da mantenere per chi sviluppa plugin o integrazioni.
Base di conoscenza
Anche la Base di conoscenza sta subendo modifiche.
Il lavoro coinvolge l'editor di contenuti, la gestione dei file, la navigazione tra gli articoli e l'organizzazione delle informazioni.
Questa è un'area importante per le aziende che utilizzano GLPI non solo per i ticket, ma anche come:
base di procedure;
portale interno di documentazione;
centro di self-service;
repository di soluzioni;
supporto per i team di assistenza.
Poiché la funzionalità è ancora in fase di test, ci sono aggiustamenti in sospeso relativi all'interfaccia, alle traduzioni, alle prestazioni e al comportamento delle categorie.
Pertanto, non è ancora possibile affermare esattamente come la Base di conoscenza verrà consegnata nella versione finale.
Asset personalizzati
Gli asset personalizzati sono state una delle principali novità di GLPI 11.
Questa funzionalità permette di creare nuovi tipi di asset senza dover modificare direttamente il codice sorgente di GLPI.
Un'azienda può utilizzare questa funzionalità per controllare, ad esempio:
macchinari industriali;
apparecchiature mediche;
veicoli;
arredi;
strumenti;
apparecchiature da laboratorio;
qualsiasi altro oggetto specifico dell'operatività.
In GLPI 12, l'aspettativa è che questi asset diventino sempre più integrati con il resto della piattaforma.
Tra i punti che devono continuare a evolversi ci sono:
ricerche;
permessi;
relazioni;
entità;
cronologie;
moduli;
regole;
API;
importazioni.
Questa evoluzione è importante perché permette di utilizzare GLPI oltre il tradizionale inventario di computer, monitor, stampanti e apparecchiature di rete.
Modernizzazione interna
Non tutti i cambiamenti saranno visibili sullo schermo.
Una parte importante del lavoro di GLPI 12 sta avvenendo nella struttura interna del sistema.
Tra i punti osservati ci sono:
refactoring del codice PHP;
riduzione del codice legacy;
maggiore utilizzo di template Twig;
creazione di componenti riutilizzabili;
sostituzione di librerie obsolete;
miglioramenti nei test automatizzati;
revisione del frontend;
miglioramenti nel sistema di traduzioni;
evoluzione delle API;
compatibilità con le versioni più recenti di PHP;
revisione della compatibilità con i database supportati.
Questo tipo di cambiamento di solito non attira tanta attenzione quanto una nuova schermata, ma è essenziale per mantenere il progetto sostenibile.
Quanto minore è la dipendenza dal codice obsoleto, tanto più facile diventa correggere i problemi, implementare nuove funzionalità e mantenere i plugin compatibili.
L'attuale documentazione tecnica di GLPI mostra già questa transizione verso un'architettura più modulare, basata su controller, template, API e componenti moderni.
API e integrazioni
Un altro punto che deve essere seguito con attenzione è l'evoluzione delle API.
Oggi molti ambienti utilizzano GLPI integrato con:
sistemi HR;
ERP;
strumenti di monitoraggio;
soluzioni di BI;
Active Directory e LDAP;
piattaforme di automazione;
n8n;
sistemi proprietari;
portali esterni;
soluzioni di inventario.
Un cambio di versione principale può modificare endpoint, permessi, campi o formati di risposta.
Per questo motivo, chi possiede integrazioni critiche deve testare principalmente:
autenticazione;
creazione e aggiornamento dei ticket;
lettura degli asset;
ricerche;
invio di documenti;
relazioni tra oggetti;
permessi degli utenti API;
risposta degli endpoint.
Non è sicuro dare per scontato che un'integrazione che funziona in GLPI 11 continuerà a funzionare allo stesso modo in GLPI 12 senza una validazione.
Sicurezza
La sicurezza continua a essere oggetto di lavoro all'interno del progetto.
Esistono già discussioni e implementazioni relative a controlli aggiuntivi per le operazioni sensibili, alla revisione dei permessi e alla riautenticazione per determinate azioni.
Ciononostante, è importante non attendere GLPI 12 per mantenere l'ambiente sicuro.
Le correzioni di sicurezza continuano a essere pubblicate nelle versioni di manutenzione di GLPI 11. Pertanto, gli ambienti di produzione devono rimanere aggiornati.
Restano valide anche le raccomandazioni di base:
non modificare il core;
mantenere i plugin aggiornati;
rimuovere i plugin abbandonati;
rivedere i permessi;
proteggere i file di configurazione;
utilizzare HTTPS;
mantenere PHP e il database aggiornati;
eseguire correttamente le azioni automatiche;
rivedere gli utenti API;
mantenere il backup del database e dei file.
Compatibilità dei plugin
Questo sarà probabilmente uno dei principali punti di attenzione nella migrazione.
Una nuova versione principale può modificare classi, metodi, hook, componenti JavaScript, template e strutture utilizzate dai plugin.
Prima di aggiornare, sarà necessario verificare:
se il plugin possiede una versione compatibile;
se il progetto continua a essere mantenuto;
quali versioni di PHP sono supportate;
se ci sono modifiche nel database;
se ci sono stati cambiamenti negli hook;
se il frontend del plugin continua a funzionare;
se i permessi restano corretti;
se le azioni automatiche funzionano;
se esiste un processo ufficiale di migrazione.
I plugin abbandonati o che modificano direttamente il comportamento del core rappresentano un rischio maggiore.
Chi possiede molti plugin installati deve iniziare i test prima del rilascio della versione stabile.
Personalizzazioni nel core
Se l'ambiente presenta modifiche direttamente nei file di GLPI, l'aggiornamento sarà più complicato.
Queste modifiche possono essere sovrascritte durante l'upgrade oppure semplicemente smettere di funzionare.
L'ideale è che le personalizzazioni vengano realizzate utilizzando:
plugin;
API;
webhook;
integrazioni esterne;
risorse ufficiali di personalizzazione.
Prima di testare GLPI 12, è importante censire tutte le modifiche esistenti nell'ambiente.
Questo include:
file PHP modificati;
template alterati;
CSS personalizzato;
JavaScript personalizzato;
modifiche manuali al database;
trigger;
view;
integrazioni;
plugin proprietari.
Senza questo censimento, diventa difficile distinguere un problema di GLPI da un problema causato da una vecchia personalizzazione.
GLPI 12 può già essere utilizzato in produzione?
No.
La versione attuale deve essere utilizzata solo in laboratorio.
Può essere utilizzata per:
conoscere la nuova interfaccia;
testare i plugin;
validare le integrazioni;
analizzare i cambiamenti tecnici;
verificare possibili incompatibilità;
testare i flussi di assistenza;
preparare il team per la migrazione.
Essendo ancora in fase di sviluppo, possono verificarsi:
errori;
regressioni;
modifiche al database;
funzionalità incomplete;
cambiamenti nell'interfaccia;
incompatibilità con i plugin;
problemi di traduzione;
cambiamenti senza preavviso.
Sconsigliamo inoltre di collegare una versione di sviluppo direttamente al database di produzione.
Il test deve essere effettuato con una copia isolata del database e dei file.
Stiamo seguendo e testando GLPI 12
In Nextools e in JMBA Soluções, stiamo già seguendo lo sviluppo di GLPI 12 ed eseguendo test con le versioni disponibili.
Il nostro obiettivo è identificare in anticipo gli impatti su:
plugin;
integrazioni;
database;
infrastruttura;
autenticazione;
API;
personalizzazioni;
processo di aggiornamento.
Per facilitare questi test, mettiamo a disposizione un'immagine Docker con la versione di sviluppo di GLPI 12.
Per scaricare:
docker pull jmbasolucoes/glpi:12-dev
L'immagine è destinata esclusivamente ai test.
Non deve essere utilizzata in produzione.
Con essa, è possibile avviare rapidamente un ambiente per:
valutare l'interfaccia;
testare i plugin;
validare LDAP e SSO;
testare le integrazioni;
analizzare l'inventario;
rivedere i moduli;
verificare le regole;
identificare incompatibilità.
Prima di testare un aggiornamento, utilizzi sempre una copia dell'ambiente.
Non colleghi questa immagine al database di produzione.
Esempio di ambiente Docker
Di seguito è riportato un semplice esempio per avviare GLPI 12 con un database dedicato al laboratorio:
services:
glpi:
image: jmbasolucoes/glpi:12-dev
container_name: glpi-12-dev
restart: unless-stopped
ports:
- "8080:80"
environment:
TZ: America/Sao_Paulo
volumes:
- ./files:/var/lib/glpi
- ./config:/etc/glpi
- ./plugins:/usr/share/glpi/plugins
- ./marketplace:/usr/share/glpi/marketplace
depends_on:
- db
db:
image: mariadb:11.4
container_name: glpi-12-dev-db
restart: unless-stopped
environment:
TZ: America/Sao_Paulo
MARIADB_DATABASE: glpi
MARIADB_USER: glpi
MARIADB_PASSWORD: altere_esta_senha
MARIADB_ROOT_PASSWORD: altere_a_senha_root
volumes:
- ./database:/var/lib/mysql
Per avviare:
docker compose up -d
Successivamente, acceda a:
http://localhost:8080
Questo compose è solo un esempio di laboratorio e deve essere adattato in base all'ambiente.
Come prepararsi per GLPI 12
Non è necessario attendere la versione stabile per iniziare la preparazione.
Il primo passo è organizzare l'ambiente attuale.
Aggiorni GLPI 11
Prima di pensare a GLPI 12, mantenga GLPI 11 aggiornato.
Migrare da una versione datata aumenta la quantità di modifiche e rende più difficile l'identificazione dei problemi.
Realizzi un inventario dei plugin
Elenchi tutti i plugin installati e registri:
versione;
sviluppatore;
finalità;
criticità;
stato di manutenzione;
dipendenze;
compatibilità.
Un plugin installato e non utilizzato deve essere rimosso.
Documenti le integrazioni
Registri:
endpoint;
metodo di autenticazione;
utente utilizzato;
campi inviati;
campi ricevuti;
frequenza;
dipendenze;
gestione degli errori.
Crei un ambiente di staging
L'ambiente di test deve riprodurre il più possibile la produzione:
PHP;
database;
plugin;
configurazioni;
autenticazione;
regole;
notifiche;
cron;
integrazioni.
Crei un piano di validazione
Non basta semplicemente aprire GLPI e verificare che la schermata si sia caricata.
È necessario testare i principali processi:
apertura dei ticket;
regole di assegnazione;
SLA;
notifiche;
moduli;
approvazioni;
attività;
inventario;
LDAP;
SSO;
azioni automatiche;
API;
report;
dashboard;
permessi;
entità.
Cosa ci aspettiamo davvero da GLPI 12
Per quanto siamo riusciti a osservare finora, GLPI 12 non sarà solo un cambio di versione.
Il progetto sta preparando una base più moderna per i prossimi anni.
I punti principali sono:
modernizzazione del frontend;
maggiore utilizzo di Vue.js;
riduzione delle dipendenze obsolete;
standardizzazione dell'interfaccia;
evoluzione degli asset personalizzati;
miglioramenti nella Base di conoscenza;
revisione delle API;
miglioramenti interni di sicurezza;
manutenzione più semplice del codice;
struttura migliore per le funzionalità future.
Non è ancora possibile affermare quali funzionalità saranno presenti nella prima versione stabile.
Inoltre, non è possibile garantire che tutto ciò che oggi appare nello sviluppo verrà consegnato esattamente nello stesso modo.
Il momento attuale è di seguire, testare e identificare gli impatti.
Chi possiede un ambiente semplice avrà probabilmente un processo di migrazione più tranquillo.
Chi possiede molti plugin, integrazioni e modifiche personalizzate deve iniziare la validazione in anticipo.
Per iniziare i test:
docker pull jmbasolucoes/glpi:12-devNei prossimi contenuti, condivideremo i test che stiamo eseguendo, le differenze rispetto a GLPI 11 e i problemi riscontrati durante questa preparazione.
Sta già testando GLPI 12? Ci racconti cosa ha funzionato, cosa si è rotto e quali cambiamenti ha riscontrato.
Avviso: questo contenuto considera lo stato di sviluppo di GLPI 12 a luglio 2026. Trattandosi di una versione ancora non stabile, funzionalità, requisiti, struttura e comportamento possono cambiare.
