NexTool Solutions

FormCreator war jahrelang eines der meistinstallierten GLPI-Plugins – und in GLPI 11 gibt es ihn als Plugin nicht mehr. Die Frage lautet nicht mehr „was ist besser“, sondern ist operativ geworden: Auf welcher Version sind Sie, und wie bringen Sie Formulare, die bereits produktiv laufen, in ein neues natives Modul, ohne den Servicekatalog zu beschädigen?

Was sich von GLPI 10 zu GLPI 11 geändert hat

In GLPI 9 und 10 ist ein benutzerdefiniertes Formular gleichbedeutend mit FormCreator: einem Community-Plugin (gepflegt von Teclib), welches Servicekatalog, bedingte Felder, Abschnitte und die automatische Ticketerstellung aus einer Antwort liefert. Die letzte eigenständige Linie ist 2.13.x – danach wurde die Entwicklung des Plugins eingestellt.

In GLPI 11 wurde diese Funktion zu einem Modul des Core: Menü Formulare, mit visuellem Editor, Abschnitten, bedingten Fragen und Destinations (was ein Formular erzeugt – Ticket oder Änderung). Ein eigenständiger FormCreator läuft unter 11 nicht. An seiner Stelle gibt es nur ein Übergangs-Plugin, Formcreator Migration Tool (Linie 3.0.x), dessen einzige Aufgabe es ist, alte Formulare in ein natives Modul zu überführen und FormCreator anschließend als End of Life (EOL) zu erklären.

Direkter Vergleich

Die Migration ist kein Zauberknopf

Ja, es gibt eine offizielle Migration – und dies widerlegt den Mythos, man müsse „alles von Hand neu anlegen“. Der Weg ist geführt: Aktualisieren Sie FormCreator noch unter GLPI 10 auf 2.13.10 oder höher, spielen Sie GLPI 11 mit dem Migration Tool ein, prüfen Sie den Umfang unter Werkzeuge > Formcreator EOL Info und führen Sie die Migration über die Kommandozeile aus.

# 1) Ainda no GLPI 10: atualize o FormCreator para a versao 2.13.10 ou superior.
# 2) Suba o GLPI 11 e instale o "Formcreator Migration Tool" (plugin 3.0.x).
# 3) Confira o volume a migrar no menu Ferramentas, item Formcreator EOL Info.
# 4) Rode a migracao pela CLI, como o usuario do servidor web
#    (Debian/Ubuntu usa www-data; RHEL/CentOS usa apache):
sudo -u www-data php bin/console migration:formcreator_plugin_to_core

# Ordem correta quando ha varios plugins legados no mesmo ambiente:
# Generic Objects, depois Fields e por ultimo o FormCreator.

Bevor Sie irgendetwas ausführen, schätzen Sie den Aufwand ab. Eine schnelle Bestandsaufnahme in der Datenbank zeigt, wie viele Formulare, Fragen und Ziele Sie danach prüfen müssen – und welche am umfangreichsten sind:

-- Inventario ANTES de migrar: rode no banco do GLPI (10, ou 11 com o
-- Migration Tool instalado) para dimensionar a conferencia pos-migracao.
SELECT
  (SELECT COUNT(*) FROM glpi_plugin_formcreator_forms WHERE is_deleted = 0) AS formularios,
  (SELECT COUNT(*) FROM glpi_plugin_formcreator_sections)                   AS secoes,
  (SELECT COUNT(*) FROM glpi_plugin_formcreator_questions)                  AS perguntas,
  (SELECT COUNT(*) FROM glpi_plugin_formcreator_targettickets)              AS alvos_de_chamado;

-- Os formularios com mais perguntas sao os que mais exigem conferencia
SELECT f.name AS formulario, COUNT(q.id) AS perguntas
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 perguntas DESC;

Was ein Werkzeug gut migriert, sind Struktur und Inhalt: Abschnitte, Fragen und Feldtypen. Menschliche Prüfung verlangt es bei der Routing-Logik – FormCreator nutzte das „Target Ticket“, um Kategorie, Template, Gruppe und Akteure des erzeugten Tickets festzulegen; nativ wird daraus Destinations, und der Import kennzeichnet im Ziel fehlende Abhängigkeiten (Einheit, Kategorie), damit Sie sie vor dem Abschluss zuordnen.

Der Zielkonflikt, der sich im Betrieb zeigt

Im Betrieb von GLPI-Umgebungen für Kunden ist der häufigste Fehler, den wir sehen, nicht technischer Natur, sondern eine Frage der Erwartung: Jemand führt den Migrationsbefehl aus, die Formulare erscheinen im neuen Menü, und ein Team betrachtet die Aufgabe als erledigt. Ist sie nicht. Migriert wird die Hülle; der Kern – welches Ticket erstellt wird, in welcher Kategorie, für welche Gruppe, mit welchem Template – ist genau jener Teil, der eine Prüfung erfordert. Deshalb migrieren wir immer zuerst in eine Abnahmeumgebung, senden pro Formular ein Testticket ab und vergleichen ein Routing Feld für Feld mit dem Verhalten des alten FormCreator.

Zwei Details erwischen jeden, der es zum ersten Mal macht. Erstens: Tabellen glpi_plugin_formcreator_* bleiben nach der Migration in der Datenbank – nichts wird gelöscht, sie werden zur Lese-/EOL-Quelle und verschwinden nicht; „alles ist weg“ bedeutet meist nur, dass ein Menü umgezogen ist. Zweitens: Native Formulare erhalten neue IDs (und UUIDs), sodass jeder direkte Link, jeder Favorit im Portal oder jede Self-Service-Verknüpfung, die auf ein FormCreator-Formular zeigte, nicht mehr funktioniert und neu verlinkt werden muss. Hinzu kommt eine stille Voraussetzung: Ist FormCreator auf einer Version unter 2.13.10, sieht ein Migration Tool die Formulare schlicht nicht – vorher zu aktualisieren verhindert eine „leere“ Migration.

Empfehlung je Szenario

Bleiben Sie bei FormCreator, wenn Ihre Umgebung GLPI 9 oder 10 ist und keine Migration auf 11 in naher Zukunft ansteht. In diesen Versionen ist er die ausgereifte Option ohne Ersatz für Servicekatalog und benutzerdefinierte Formulare. Praktische Empfehlung: Halten Sie ihn auf 2.13.10 oder höher, auch wenn Sie jetzt nicht migrieren – so bleibt eine Tür zur Migration offen, wenn 11 kommt.

Nutzen Sie native Formulare, wenn Sie auf GLPI 11 sind (oder migrieren werden). Hier gibt es nichts zu entscheiden: Ein eigenständiger FormCreator läuft unter 11 nicht, und ein natives Modul ist der Weg – ohne Plugin, um welches man sich beim Upgrade kümmern muss, mit Export/Import von Formularen zwischen Umgebungen in JSON (etwas, was FormCreator nie nativ konnte) und Abgleich von Abhängigkeiten im Ziel.

Bei der Migration von 10 auf 11 verwenden Sie ein offizielles Werkzeug, behandeln die Sache aber als Projekt und nicht als Befehl: Formulare inventarisieren, den Prüfaufwand anhand der Anzahl von Fragen und Bedingungen abschätzen, in eine Abnahmeumgebung migrieren, ein Routing jedes Formulars validieren und erst dann übernehmen. Gibt es mehrere Legacy-Plugins, halten Sie die Reihenfolge ein, welche die Dokumentation selbst vorgibt: Generic Objects, danach Fields, danach FormCreator.

Kosten und Aufwand

Die Lizenz ist nicht die entscheidende Achse: FormCreator und native Formulare sind kostenlos, und unter 11 ist die native Lösung bereits im Core enthalten. Echte Kosten entstehen durch Migration und Prüfung. Der automatische Teil – bin/console ausführen – dauert je nach Volumen Minuten bis einige Dutzend Minuten. Personalzeit verbraucht ein anderer Teil: Routing validieren und Ziel-Logik neu anlegen, die nicht 1:1 übernommen wurde. Als ehrliche Spanne: Bei wenigen einfachen Formularen passt die gesamte Migration in einen Nachmittag; bei Dutzenden Formularen mit vielen Bedingungen, Akteuren und Templates planen Sie Tage der Prüfung in einer Abnahmeumgebung ein, bevor Sie in der Produktion freigeben.

Bei NexTool führen wir GLPI bei Kunden in beiden Generationen ein, betreiben es und begleiten die Migration von FormCreator zu nativen Formularen, ohne den Servicekatalog lahmzulegen. Wenn Sie GLPI 10 verlassen und nicht erst in der Produktion entdecken wollen, was die Migration nicht übernommen hat, decken unsere Einführungs- und Migrationsprojekte diesen Weg von Anfang bis Ende ab.

Geprüft vom Team der NexTool Solutions.