Ein benutzerdefiniertes Feld in GLPI ist eine Architekturentscheidung, kein Mausklick. Die richtige Frage lautet nicht "Fields oder nativ?", sondern: Sind die Daten, die Sie speichern müssen, ein Attribut von etwas bereits Vorhandenem, oder sind sie etwas Neues mit eigenem Lebenszyklus? Diese Antwort bestimmt das Werkzeug - und die Kosten, die Sie in den kommenden Jahren tragen.
Was jeder Ansatz wirklich löst
Das Plugin Fields (gepflegt von Teclib) hängt zusätzliche Felder an Objekttypen, die es in GLPI bereits gibt: Ticket, Computer, Benutzer, Vertrag, Lieferant. Sie erstellen einen Container (einen Block von Feldern), wählen, in welchen Typen er erscheint, und fügen Felder vom Typ Text, Dropdown, Datum, Zahl, Ja/Nein und URL hinzu. Es bleibt der praktische Weg, um zu sagen: "Jedes Ticket braucht ein Feld Kostenstelle".
Die benutzerdefinierten Objekte von GLPI 11 (benutzerdefinierte Assets) lösen ein anderes Problem: Sie erstellen einen neuen Objekttyp direkt im Core, ohne Plugin. Sie sind der offizielle Nachfolger des alten GenericObject. Sie definieren "Fahrzeug", "Besprechungsraum" oder "Laborgerät" mit eigenen Feldern, und der Typ verhält sich wie ein vollwertiges Asset: Er wird inventarisiert, mit Tickets verknüpft und erscheint in Berichten.
Die Grenze zusammengefasst: Fields fügt etwas Bestehendem Attribute hinzu; ein natives Objekt erstellt die Entität. Wer beides verwechselt, schafft die Ursache für fast jeden Wartungsschmerz, der später auftritt.
Direkter Vergleich
| Kriterium | Plugin Fields | Benutzerdefiniertes Objekt (GLPI 11 nativ) |
|---|---|---|
| Was es tut | Fügt bestehenden Typen Felder hinzu | Erstellt einen neuen Objekttyp |
| Abhängig von einem Plugin | Ja - harte Abhängigkeit beim Major-Upgrade | Nein - im Core enthalten |
| Wo die Daten gespeichert werden | Eine Tabelle pro Container, parallel zum Core | Im nativen Schema von GLPI |
| Bedingte Felder / pro Profil | Ja, aber die Sichtbarkeit ist Anzeige, keine Sicherheit | Keine fertige native Bedingungslogik |
| Suche und Berichte | Search Options mit einem LEFT JOIN pro Container | Native Search Options, ohne zusätzliche Tabelle |
| Integration mit dem Inventar | Erhält keine Inventardaten | Ja, es ist ein inventarisierbares Asset |
| Migration von GLPI 10 auf 11 | Erfordert eine mit dem neuen Core kompatible Plugin-Version | Offizielles Ziel für GenericObject |
| Aufwand für den Einstieg | Minuten für ein Feld | Stunden für die Modellierung eines Typs |
| Am besten geeignet für | Attribute von etwas bereits Vorhandenem | Neue Entität mit eigenem Lebenszyklus |
Wo die Daten liegen (und warum es wichtig ist)
Jeder Container von Fields wird zu einer eigenen Tabelle in der Datenbank, mit einer Zeile pro Objekt und einer Spalte pro Feld. Bevor Sie entscheiden, lohnt sich ein Blick darauf, was in der Umgebung bereits existiert:
-- Where the Fields plugin stores values: one table per container,
-- with one row per item and one column per custom field.
SELECT table_name AS container_table
FROM information_schema.tables
WHERE table_schema = DATABASE()
AND table_name LIKE 'glpi_plugin_fields_%'
ORDER BY table_name;
-- Definitions: containers (which types they apply to) and each one's fields
SELECT c.name AS container, c.itemtypes, f.name AS field, 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;Dies ist aus zwei betrieblichen Gründen wichtig. Erstens: Jedes als durchsuchbar markierte Feld von Fields wird zu einer Search Option, und die Suchmaschine von GLPI löst sie mit einem zusätzlichen LEFT JOIN auf die Tabelle des Containers auf. Bei Kunden mit 15 oder mehr Containern am Ticket wird die Ticketliste langsam - nicht wegen der Datenmenge, sondern wegen der JOINs im SELECT der Suche. Zweitens: Native Objekte speichern im Schema des Core, erscheinen also in Export, API und Bericht genauso wie die Standardfelder, ohne parallele Tabelle, die abgeglichen werden muss.
Der Zielkonflikt, der sich im Support zeigt
Im Support von GLPI-Landschaften für Kunden liegen die echten Kosten von Fields nicht in der Installation - sondern am Tag des Major-Upgrades. Fields ist eine harte Abhängigkeit: Bei einer Migration von GLPI 10 auf 11 startet die Umgebung erst, wenn es eine mit dem neuen Core kompatible Plugin-Version gibt. Wir haben schon Upgrade-Fenster von Kunden zurückgehalten, weil wir darauf warteten, dass das Plugin den kompatiblen Build veröffentlicht, mit Dutzenden Containern in der Produktion, die sich nicht abschalten ließen. Ein natives Objekt hat diese Hürde nicht: Es ist der Core und startet mit.
Zwei häufige Fehler, die wir oft korrigieren. Der erste besteht darin, eine ganze Entität als Stapel von Feldern am Ticket zu modellieren - ein "Wartungsvertrag" wird zu 12 Fields-Feldern am Ticket, die sich nicht vernünftig auflisten, filtern oder verknüpfen lassen; hier hätte ein Objekt gepasst (oder das Vertragsmodul von GLPI selbst). Der zweite ist das Gegenteil: ein komplettes benutzerdefiniertes Asset für etwas zu erstellen, was eigentlich zwei organisatorische Attribute an einem bestehenden Typ waren - Modellierungskomplexität ohne Gegenwert. Und eine Warnung, die wir immer aussprechen: Ein Feld von Fields pro Profil auszublenden ist Anzeige, keine Sicherheit. Der Wert bleibt in der Datenbank und gelangt über API, Export oder Suche nach außen. Wenn die Daten sensibel sind, braucht es eine andere Kontrolle.
Urteil nach Szenario
Nutzen Sie Fields, wenn die Daten ein Attribut eines bereits vorhandenen Typs sind und Sie keinen neuen Typ verwalten wollen: Kostenstelle und Projekt am Ticket, interne Inventarnummer am Computer, Personalnummer am Benutzer, Pflichtfelder oder bedingte Felder je ITIL-Kategorie des Tickets. Es geht schnell, ohne Ausfallzeit und ohne Schemamigration, die Sie verwalten müssten.
Nutzen Sie ein natives benutzerdefiniertes Objekt, wenn die "Sache" einen eigenen Lebenszyklus hat und Sie sie wie ein Objekt auflisten, filtern und mit Tickets verknüpfen werden: Fahrzeuge, Räume, Laborassets, Geräte, die in keinen Standardtyp passen. Und zwingend, wenn Sie bei der Migration auf GLPI 11 von GenericObject weggehen - es ist der offizielle Ersatzweg.
Beide können nebeneinander bestehen. Es ist legitim, ein benutzerdefiniertes Asset für die Entität zu haben und trotzdem mit Fields das eine oder andere organisatorische Attribut an Tickets zu hängen, die auf dieses Asset verweisen. Was nicht geht: das eine für die Arbeit des anderen zu nutzen.
Kosten und Aufwand
Lizenz: Beide sind kostenlos (GPL). Die eigentlichen Kosten liegen in der Wartung. Fields kostet Abhängigkeitsrisiko bei jedem Major-Upgrade und Suchlast, je mehr Container es gibt. Ein natives Objekt kostet anfängliche Modellierung - Sie entwerfen einen Typ, statt ein Feld hinzuzufügen -, belastet danach aber weder Upgrades noch parallele JOINs. Als ehrliche Spanne: Ein Fields-Feld hinzuzufügen dauert Minuten; ein sauber modelliertes benutzerdefiniertes Asset dauert einige Stunden bis zu einem Tag, einschließlich Feldern, Profilen und Inventar.
Bei NexTool implementieren und betreuen wir beide Ansätze in GLPI-Umgebungen von Kunden. Wenn Sie zwischen weiteren angehängten Feldern und der Modellierung eines Objekts abwägen - oder GenericObject verlassen müssen, ohne den Verlauf zu zerstören -, hilft unsere GLPI-Beratung, diese Entscheidung zu treffen, bevor sie zur technischen Schuld wird.
Geprüft vom Team von NexTool Solutions.
