FormCreator è stato, per anni, il plugin più installato di GLPI - e in GLPI 11 smette di esistere come plugin. La domanda non è più "quale è meglio", ma una operativa: su quale versione è e come porta i moduli già in produzione al nuovo modulo nativo senza rompere il catalogo dei servizi.
Cosa è cambiato da GLPI 10 a GLPI 11
Su GLPI 9 e 10, modulo personalizzato è sinonimo di FormCreator: un plugin della comunità (mantenuto da Teclib) che offre catalogo dei servizi, campi condizionali, sezioni e generazione automatica del ticket a partire dalle risposte. L'ultima linea standalone è la 2.13.x - da lì in poi lo sviluppo del plugin si è fermato.
Su GLPI 11 quella funzionalità è diventata un modulo del core: il menu Moduli, con editor visuale, sezioni, domande condizionali e destinations (ciò che il modulo genera - ticket o modifica). FormCreator standalone non funziona su 11. Al suo posto esiste solo un plugin di transizione, il Formcreator Migration Tool (linea 3.0.x), la cui unica funzione è portare i vecchi moduli al modulo nativo e poi dichiarare FormCreator a fine vita (EOL).
Confronto diretto
| Criterio | FormCreator (GLPI 9/10) | Moduli nativi (GLPI 11) |
|---|---|---|
| Natura | Plugin della comunità (Teclib) | Modulo del core, senza plugin |
| Compatibilità | GLPI 9 e 10 (linea 2.13.x) | GLPI 11+ |
| Editor visuale | Sezioni, domande e condizioni | Editor con sezioni e condizioni native |
| Campi condizionali | Sì, per domanda e per sezione | Sì, condizioni native |
| Generazione del ticket | "Target" (ticket, modifica, problema) | "Destinations" (ticket, modifica) |
| Dove salva le definizioni | Tabelle glpi_plugin_formcreator_* | Tabelle glpi_forms_* |
| Dove salva le risposte | Tabelle del plugin stesso | Insieme di risposte (answers set) nel core |
| Export/import tra ambienti | Limitato al plugin stesso | Nativo, in JSON, con riconciliazione delle dipendenze |
| Futuro / manutenzione | Congelato (EOL dopo la migrazione) | Mantenuto da Teclib nel core |
| Migrazione 10 a 11 | Origine (Migration Tool 3.0.x) | Destinazione ufficiale della migrazione |
| Costo | Gratuito (GPL) | Incluso nel core |
La migrazione non è un pulsante magico
Esiste, sì, una migrazione ufficiale - e questo smonta il mito che "bisogna ricreare tutto a mano". Il percorso è assistito: aggiorni FormCreator a 2.13.10 o superiore ancora su GLPI 10, avvii GLPI 11 con il Migration Tool, verifichi il volume in Strumenti > Formcreator EOL Info ed esegua la migrazione da riga di comando.
# 1) Ancora su GLPI 10: aggiorna FormCreator alla versione 2.13.10 o superiore.
# 2) Avvia GLPI 11 e installa il "Formcreator Migration Tool" (plugin 3.0.x).
# 3) Verifica il volume da migrare nel menu Strumenti, voce Formcreator EOL Info.
# 4) Esegui la migrazione dalla CLI, come utente del server web
# (Debian/Ubuntu usa www-data; RHEL/CentOS usa apache):
sudo -u www-data php bin/console migration:formcreator_plugin_to_core
# Ordine corretto quando piu plugin legacy convivono nello stesso ambiente:
# Generic Objects, poi Fields e infine FormCreator.Prima di eseguire qualsiasi cosa, dimensioni il lavoro. Un inventario rapido nel database dice quanti moduli, domande e target dovrà verificare dopo - e quali sono i più pesanti:
-- Inventario PRIMA di migrare: eseguilo sul database GLPI (10, o 11 con il
-- Migration Tool installato) per dimensionare la verifica post-migrazione.
SELECT
(SELECT COUNT(*) FROM glpi_plugin_formcreator_forms WHERE is_deleted = 0) AS moduli,
(SELECT COUNT(*) FROM glpi_plugin_formcreator_sections) AS sezioni,
(SELECT COUNT(*) FROM glpi_plugin_formcreator_questions) AS domande,
(SELECT COUNT(*) FROM glpi_plugin_formcreator_targettickets) AS target_ticket;
-- I moduli con piu domande sono quelli che richiedono piu verifica
SELECT f.name AS modulo, COUNT(q.id) AS domande
FROM glpi_plugin_formcreator_forms f
LEFT JOIN glpi_plugin_formcreator_sections s
ON s.plugin_formcreator_forms_id = f.id
LEFT JOIN glpi_plugin_formcreator_questions q
ON q.plugin_formcreator_sections_id = s.id
WHERE f.is_deleted = 0
GROUP BY f.id, f.name
ORDER BY domande DESC;Ciò che lo strumento migra bene è struttura e contenuto: sezioni, domande e tipi di campo. Dove chiede verifica umana è la logica di instradamento - FormCreator usava il "target ticket" per definire categoria, template, gruppo e attori del ticket generato; nel nativo diventa destinations, e l'import segnala le dipendenze mancanti sulla destinazione (entità, categoria) da mappare prima di concludere.
Il trade-off che emerge nel supporto
Quando gestisce parchi GLPI per i clienti, l'errore più comune non è tecnico, è di aspettativa: qualcuno esegue il comando di migrazione, i moduli compaiono nel menu nuovo e il team considera l'attività chiusa. Non lo è. Ciò che migra è il guscio; il nocciolo - quale ticket viene aperto, in quale categoria, per quale gruppo, con quale template - è proprio ciò che richiede verifica. Per questo migriamo sempre prima in collaudo, inviamo un ticket di test per modulo e confrontiamo l'instradamento con il comportamento del vecchio FormCreator, campo per campo.
Due dettagli fregano chi lo fa per la prima volta. Primo: le tabelle glpi_plugin_formcreator_* restano nel database dopo la migrazione - nulla viene cancellato, diventano una fonte di lettura/EOL e non spariscono, quindi "è sparito tutto" di solito è solo il menu che si è spostato. Secondo: i moduli nativi ricevono ID (e UUID) nuovi, quindi qualsiasi link diretto, preferito del portale o scorciatoia di self-service che puntava a un modulo FormCreator smette di funzionare e va ripuntato. E c'è il prerequisito silenzioso: se FormCreator è in una versione precedente alla 2.13.10, il Migration Tool semplicemente non vede i moduli - aggiornare prima di tutto è ciò che evita la migrazione "vuota".
Verdetto per scenario
Resti su FormCreator quando l'ambiente è GLPI 9 o 10 e non c'è una migrazione a 11 all'orizzonte vicino. Su quelle versioni è l'opzione matura e senza sostituto per catalogo dei servizi e moduli personalizzati. Consiglio pratico: lo tenga su 2.13.10 o superiore anche senza migrare ora - è ciò che lascia aperta la porta della migrazione quando arriverà 11.
Usi i moduli nativi quando è su GLPI 11 (o sta per migrare). Qui non c'è decisione da prendere: FormCreator standalone non funziona su 11, e il modulo nativo è la via - nessun plugin da gestire all'upgrade, con export/import di moduli tra ambienti in JSON (cosa che FormCreator non ha mai fatto nativamente) e riconciliazione delle dipendenze sulla destinazione.
Migrando da 10 a 11, usi lo strumento ufficiale ma lo tratti come un progetto, non come un comando: inventari i moduli, dimensioni la verifica in base al numero di domande e condizioni, migri in collaudo, validi l'instradamento di ogni modulo e solo allora promuova. Se convivono più plugin legacy, rispetti l'ordine che la documentazione stessa indica: Generic Objects, poi Fields, poi FormCreator.
Costo e sforzo
La licenza non è l'asse della decisione: FormCreator e moduli nativi sono gratuiti, e su 11 il nativo è già nel core. Il costo reale è quello della migrazione e della verifica. La parte automatica - eseguire bin/console - richiede da minuti a qualche decina di minuti a seconda del volume. La parte che consuma tempo delle persone è validare l'instradamento e ricostruire la logica di destinazione che non è passata 1:1. Come intervallo onesto: per pochi moduli semplici, l'intera migrazione sta in un pomeriggio; per decine di moduli con molte condizioni, attori e template, pianifichi giorni di verifica in collaudo prima di andare in produzione.
In NexTool implementiamo e manteniamo GLPI per i clienti su entrambe le generazioni e conduciamo la migrazione da FormCreator ai moduli nativi senza far cadere il catalogo dei servizi. Se sta lasciando GLPI 10 e non vuole scoprire in produzione ciò che la migrazione non ha portato, i nostri progetti di implementazione e migrazione coprono questo percorso da un capo all'altro.
Revisionato dal team NexTool Solutions.
