Benutzerdefinierte Felder sind nicht nur eine Funktion: So bewerten Sie die Flexibilität des Datenmodells in einer selbst gehosteten Unternehmensanwendung
Benutzerdefinierte Felder können eine Unternehmensanwendung an Ihre Prozesse anpassen – oder zu uneinheitlichen, unzugänglichen und schwer migrierbaren Daten führen. Nutzen Sie diesen evidenzbasierten Rahmen, um das zugrunde liegende Datenmodell zu prüfen, bevor Sie operative Datenbestände festlegen.
Benutzerdefinierte Felder sind eine Entscheidung der Daten-Governance, kein Kontrollkästchen
Die Aussage „benutzerdefinierte Felder unterstützt“ auf einer Produktseite beantwortet nur sehr wenig. Ein Feld kann ein uneingeschränktes Textfeld, eine kontrollierte Liste zulässiger Werte, eine Verknüpfung zu einem anderen Datensatz oder eine wiederholbare Tabelle mit zugehörigen Datensätzen sein. Diese Entscheidungen bestimmen, ob Personen konsistente Daten erfassen können, ob die Anwendung Geschäftsregeln durchsetzen kann und ob die Informationen in Berichten, Exporten und Integrationen nützlich bleiben.
Behandeln Sie die Bewertung als Frage der Eignung des Datenmodells: Kann die Anwendung die Entitäten, Beziehungen und Regeln abbilden, die Ihr Betrieb tatsächlich verwendet? Eine kurze Konfigurationsdemo ist kein ausreichender Nachweis. Sie müssen sehen, wie sich dieselben benutzerdefinierten Informationen verhalten, wenn Datensätze erstellt, bearbeitet, finalisiert, gesucht, exportiert, importiert und von Nutzern mit unterschiedlichen Berechtigungen abgerufen werden.
Dies ist besonders wichtig bei einer selbst gehosteten Anwendung. Das Hosting gibt Ihnen Kontrolle darüber, wo die Arbeitslast ausgeführt wird, entscheidet aber nicht, welche Felder vorhanden sein sollten, wer darauf zugreifen darf, wie ein ausgemusterter Wert interpretiert wird oder ob eine Integration von einer Felddefinition abhängt. Das sind Governance-Entscheidungen, die Ihre Organisation treffen muss.
- Bewerten Sie nicht nur „benutzerdefinierte Felder: ja/nein“. Bewerten Sie den vollständigen Lebenszyklus eines repräsentativen Feldes.
- Trennen Sie die Benutzerfreundlichkeit der Oberfläche von durchgesetzten Datenregeln und Zugriffskontrollen.
- Fordern Sie Nachweise in einer Testumgebung mit Ihren eigenen realistischen Datensätzen an, nicht nur anhand von Herstellerbeispielen.
Beginnen Sie mit einem kleinen, realistischen Datensatzmodell
Bevor Sie eine Testinstanz öffnen, halten Sie einen kleinen, aber folgenreichen Workflow schriftlich fest. Ein Datensatz zur Leistungserbringung, ein Kundenkonto, eine Beschaffungsanforderung oder ein Projektänderungsantrag ist meist ein besserer Ausgangspunkt als eine abstrakte Liste gewünschter Felder. Nehmen Sie Informationen auf, die für den gesamten Datensatz gelten, Informationen, die zu einer anderen Entität gehören, und Informationen, die sich wiederholen.
Entscheiden Sie für jedes Element, was es strukturell bedeutet. Eine Freitextnotiz ist angemessen, wenn Variationen erwartet werden und keine verlässliche Gruppierung erforderlich ist. Ein kontrollierter Wert eignet sich besser für einen Geschäftsstatus, eine Kategorie oder einen Grund, nach denen konsistent gefiltert und berichtet werden muss. Eine Beziehung ist angemessen, wenn der Wert in Wirklichkeit eine andere gepflegte Entität ist, etwa ein Kunde, Lieferant oder Verantwortlicher. Wiederkehrende zugehörige Elemente sollten als wiederholte Zeilen modelliert werden, sofern die Anwendung dieses Muster unterstützt, statt sie in ein durch Kommas getrenntes Textfeld zu packen.
Die Dokumentation von Frappe veranschaulicht diese Unterschiede: Data ist allgemeiner Text; Select verwendet Werte, die in seinen Optionen angegeben sind; Link stellt eine Verbindung zu einem anderen Stammdatensatz her; und Table repräsentiert eine Child-Table-Beziehung. Die Dokumentation zu Child DocType beschreibt Child-Datensätze zudem als an ein übergeordnetes Element angehängt, wobei Informationen zum übergeordneten Element und zur Zeilenreihenfolge erhalten bleiben. Die genauen Bezeichnungen unterscheiden sich zwischen Produkten, doch die Bewertungsfrage ist universell: Entspricht die verfügbare Struktur der Bedeutung Ihrer Informationen? Siehe die Frappe-Dokumentation zu Field Types (https://docs.frappe.io/framework/user/en/basics/doctypes/fieldtypes) und zu Child / Table DocType (https://docs.frappe.io/framework/user/en/basics/doctypes/child-doctype).
- Listen Sie die primären Entitäten auf: zum Beispiel Kunde, Projekt, Anfrage und Person.
- Identifizieren Sie Eins-zu-eins-, Eins-zu-viele- und Viele-zu-eins-Beziehungen.
- Kennzeichnen Sie jeden Wert, der kontrolliert statt frei eingegeben werden muss.
- Identifizieren Sie sich wiederholende Daten, etwa mehrere Kontakte, Meilensteine, Positionen oder Freigaben.
- Notieren Sie die Geschäftsregeln, die einen Datensatz vollständig oder gültig machen.
Prüfen Sie Feldtypen und Regeln in der offiziellen Dokumentation
Lesen Sie die offizielle Dokumentation der Anwendung zu Feldtypen und Regelkonfiguration und überprüfen Sie diese Fähigkeiten anschließend in der Version, die Sie einsetzen möchten. Schauen Sie über die Frage hinaus, ob ein Feld hinzugefügt werden kann. Stellen Sie fest, ob es erforderlich sein, mit einem Standardwert versehen, validiert, auf kontrollierte Werte begrenzt sowie bedingt erforderlich oder schreibgeschützt gemacht werden kann.
Frappe dokumentiert beispielsweise unabhängige Einstellungen für Standardwerte, mandatory_depends_on und read_only_depends_on. Damit lassen sich grundsätzlich Regeln testen, etwa dass bei Erreichen eines bestimmten Status ein Grund erforderlich wird oder dass weitere Änderungen verhindert werden, sobald eine Bedingung erfüllt ist. Schließen Sie nicht darauf, dass eine andere Anwendung identisches Verhalten bietet, nur weil beide benutzerdefinierte Felder anbieten. Siehe die Frappe-Dokumentation zu DocField: https://docs.frappe.io/framework/user/en/basics/doctypes/docfield.
Testen Sie ungültige Eingaben gezielt. Kann ein Nutzer einen erforderlichen Wert leer lassen? Kann er eine ungültige Kategorie auswählen? Ist ein Standardwert sichtbar und verständlich? Setzt die Anwendung die Regel beim Speichern, beim Import und über die API durch, sofern diese Wege relevant sind? Eine Regel, die nur in einem Formular funktioniert, kann an anderer Stelle dennoch zu uneinheitlichen Datensätzen führen.
- Erstellen Sie ein Pflichtfeld und versuchen Sie, ohne dessen Ausfüllung zu speichern.
- Fügen Sie einen Standardwert hinzu und prüfen Sie, wann er angewendet wird.
- Verwenden Sie ein Feld mit kontrollierten Werten für eine Berichtskategorie; versuchen Sie, einen nicht genehmigten Wert einzugeben.
- Testen Sie eine Bedingung, durch die ein Feld erforderlich oder schreibgeschützt wird.
- Dokumentieren Sie, ob jede Regel in der Oberfläche, bei Importen und über unterstützte APIs durchgesetzt wird.
Testen Sie Konsistenz über Datensätze, Teams und Workflows hinweg
Eine brauchbare Konfiguration muss im Maßstab Ihres Betriebs konsistent angewendet werden. Erstellen Sie mehrere Datensätze über den normalen Workflow, möglichst mit unterschiedlichen Nutzern oder Rollen. Bestätigen Sie, dass jedes Team dieselben vorgesehenen Felddefinitionen, Standardwerte und kontrollierten Werte sieht, sofern die Richtlinie Konsistenz verlangt.
Achten Sie besonders auf Workflow-Grenzen. Ein Feld, das nach der Finalisierung eines Dokuments bearbeitet werden kann, kann seine Bedeutung, seinen Status, seinen Wert oder nachgelagerte Auswirkungen verändern. Die Frappe-Anleitung zu Allow on Submit warnt ausdrücklich davor, dass nach dem Absenden bearbeitbare Felder sicher änderbar sein sollten, und verweist auf Abhängigkeiten in Berichten, Workflows, Integrationen, Berechtigungen und serverseitiger Logik. Wenden Sie dieses Prinzip auch an, wenn Sie eine andere Plattform bewerten. Siehe die Frappe-Dokumentation zu Allow on Submit: https://docs.frappe.io/framework/doctypes/allow-on-submit.
Wenn ein Prozess historische Richtigkeit benötigt, entscheiden Sie, welche Werte nach der Genehmigung oder Finalisierung unveränderlich bleiben müssen und welche betrieblich sicher angepasst werden können. Halten Sie das Ergebnis als Regel fest, nicht als informelle Erwartung.
- Erstellen Sie gleichwertige Datensätze in mehr als einem Teamkontext.
- Vergleichen Sie Feldverfügbarkeit, Werte und Standardwerte.
- Führen Sie einen Datensatz durch seine relevanten Status- oder Genehmigungsstufen.
- Versuchen Sie nach der Finalisierung erlaubte und verbotene Änderungen.
- Identifizieren Sie Berichte, Integrationen und Berechtigungen, die von jedem bearbeitbaren Feld betroffen sind.
Bewerten Sie Berechtigungen getrennt für Datensätze, Felder, Berichte, Exporte und Importe
Die Prüfung von Berechtigungen sollte nicht bei „Kann dieser Nutzer den Datensatz öffnen?“ enden. Bestimmen Sie, wer Datensätze anzeigen, erstellen, bearbeiten und löschen darf; wer sensible Felder sehen oder bearbeiten darf; und wer die Felddefinition selbst ändern kann. Testen Sie außerdem Berichte, Exporte und Importe unabhängig voneinander. Eine Person, die einen Datensatz nicht ändern darf, kann möglicherweise dennoch Informationen exportieren, wenn diese Fähigkeit separat gewährt wird.
Frappe dokumentiert separate Berechtigungen zum Lesen, Schreiben, Erstellen, Löschen, Anzeigen von Berichten, zum CSV-/Excel-Export und zur Verwendung seines Data Import Tool. Außerdem werden Berechtigungsstufen dokumentiert, die Felder gruppieren und jeder Stufe unterschiedliche Rollen zuweisen können. Diese Beispiele zeigen, warum eine einzige breit angelegte Berechtigungsprüfung unzureichend ist. Siehe die Frappe-Dokumentation zu Users and Permissions: https://docs.frappe.io/framework/user/en/basics/users-and-permissions.
Behandeln Sie ausgeblendete Felder nicht standardmäßig als sicher. Klären Sie anhand der offiziellen Produktdokumentation und eines Tests mit einem eingeschränkten Konto, ob sensible Felder aus Formularen, Berichten, Exporten und unterstützten Fernzugriffsmethoden ausgelassen werden – und ob direkte Versuche, sie zu lesen oder zu schreiben, abgelehnt werden. Testen Sie das Verhalten des konkreten Produkts und der konkreten Version, die Sie in Betracht ziehen, statt anzunehmen, dass eine Sichtbarkeitseinstellung zugleich eine Zugriffskontrolle ist.
- Testen Sie einen Standardnutzer, eine Führungskraft, einen Reporting-Nutzer und einen Administrator.
- Versuchen Sie mit jeder Rolle, sensible Feldwerte anzuzeigen, zu bearbeiten und zu erstellen.
- Testen Sie Berichtszugriff und Datenexport als getrennte Aktionen.
- Testen Sie, ob ein Importnutzer eingeschränkte Felder befüllen kann.
- Nutzen Sie ein eingeschränktes Konto, um unterstützte API-Lese- und Schreibzugriffe auf sensible Daten zu versuchen.
- Dokumentieren Sie, wer Felddefinitionen und Listen kontrollierter Werte ändern kann.
Prüfen Sie, ob benutzerdefinierte Daten dort funktionieren, wo Entscheidungen getroffen werden
Ein benutzerdefiniertes Feld ist nur dann betrieblich wertvoll, wenn Menschen es über das Datensatzformular hinaus nutzen können. Testen Sie es in Listenansichten, Filtern, Sortierungen, gespeicherten Ansichten, Dashboards, Berichten und Exporten. Prüfen Sie, ob die Ergebnisse verständlich sind, wenn ein Feld leer ist, wenn sich Werte im Lauf der Zeit ändern und wenn ein Datensatz mehrere untergeordnete Zeilen enthält.
Frappe dokumentiert Listenfunktionen einschließlich Filtern, Sortieren und Seitennavigation sowie Query Reports mit konfigurierbaren Spalten und Filtern, die zur Zugriffskontrolle an einen Referenz-DocType gebunden sind. Dies sind nützliche Fähigkeiten, nach denen Sie suchen sollten, nicht die Annahme, dass jede Anwendung benutzerdefinierte Felder auf dieselbe Weise verfügbar macht. Siehe die Frappe-Dokumentation zu List: https://docs.frappe.io/framework/user/en/api/list.
Nutzen Sie eine Frage aus Ihrem wöchentlichen Betriebsrhythmus. Zum Beispiel: „Welche aktiven Anfragen haben einen Grund mit hohem Risiko und keinen zugewiesenen Verantwortlichen?“ Wenn Sie diese Frage nicht zuverlässig beantworten können, ohne Datensätze manuell zu öffnen oder eine Tabelle zu exportieren und nachzubearbeiten, hat das vorgeschlagene Felddesign seinen Wert noch nicht bewiesen.
- Filtern Sie Datensätze nach jedem wichtigen benutzerdefinierten Feld.
- Sortieren Sie gegebenenfalls nach einem Datums-, Zahlen- oder Feld mit kontrollierten Werten.
- Erstellen oder prüfen Sie einen Bericht, der benutzerdefinierte Felder und Beziehungsdaten enthält.
- Exportieren Sie einen repräsentativen Datensatzbestand und prüfen Sie Spaltennamen, Werte und leere Felder.
- Prüfen Sie, ob Bericht- und Exportberechtigungen Ihrer Zugriffsrichtlinie entsprechen.
Verfolgen Sie benutzerdefinierte Felder durch APIs, Importe und verbundene Anwendungen
Eine Integration kann aus einem gut gestalteten Feld eine fragile Abhängigkeit machen, wenn sein Name, seine zulässigen Werte, seine Berechtigungen oder sein Aktualisierungsverhalten unklar sind. Identifizieren Sie jeden Weg, über den ein repräsentativer Datensatz erstellt oder geändert werden kann: die Anwendungsoberfläche, Importe, eine unterstützte API und jeden verbundenen Workflow, den Sie einsetzen möchten.
Die REST-Dokumentation von Frappe beschreibt das Auswählen von Feldern, das Filtern nach Bedingungen, das Sortieren und das Pagieren von Datensätzen. Diese dokumentierten Verhaltensweisen veranschaulichen einen wirksamen Test: Prüfen Sie, ob Ihre benutzerdefinierten Felder auf Anfrage zurückgegeben werden und bei Bedarf gefiltert werden können. Testen Sie separat jedes für Ihre Integration erforderliche Erstellen, Aktualisieren oder Löschen anhand der offiziellen Dokumentation und der Version, die Sie einsetzen möchten. Siehe die Frappe-Dokumentation zur REST API: https://docs.frappe.io/framework/user/en/api/rest.
Massenoperationen verdienen einen eigenen Test. Die Data-Import-Dokumentation von ERPNext besagt, dass hochgeladene Tabellen vor dem Import validiert werden, Warnungen nach Zeile oder Spalte angezeigt und vor dem Import behoben werden müssen und erfolgreiche Importe in einem Importprotokoll erfasst werden. Unabhängig davon, ob Ihre gewählte Anwendung auf diese Weise arbeitet, sollten Sie feststellen, ob Fehler erkannt werden, bevor Geschäftsdaten verbindlich übernommen werden, und ob das Ergebnis prüfbar ist. Siehe die ERPNext-Dokumentation zu Data Import: https://docs.frappe.io/erpnext/data-import.
- Erstellen Sie einen repräsentativen Datensatz über jeden erforderlichen unterstützten Weg.
- Lesen Sie ihn zurück und vergleichen Sie jeden benutzerdefinierten Wert mit der Quelle.
- Aktualisieren Sie ein erlaubtes Feld und bestätigen Sie die erwarteten Workflow-Auswirkungen.
- Versuchen Sie eine ungültige Aktualisierung und prüfen Sie den Fehler sowie den resultierenden Zustand des Datensatzes.
- Testen Sie Feldauswahl, Filterung, Sortierung und Seitennavigation in der API, wenn Integrationen dies benötigen.
- Führen Sie einen kleinen Import mit gültigen und absichtlich ungültigen Zeilen durch.
Bewerten Sie die Sicherheit von Schemaänderungen, bevor Sie sie benötigen
Felder entwickeln sich weiter. Teams benennen Kategorien um, ersetzen Prozesse und nehmen Werte außer Betrieb. Die wesentliche Frage ist nicht nur, ob ein Administrator eine Änderung vornehmen kann, sondern was danach mit bestehenden Datensätzen, Berichten, Integrationen und der historischen Interpretation geschieht.
Führen Sie für jedes relevante Feld ein Änderungsregister: Geschäftszweck, Verantwortlicher, Typ, zulässige Werte, Standardwert, Validierung, Zugriffsrichtlinie, Abhängigkeiten und Vorgehen bei der Ausmusterung. Identifizieren Sie vor der Freigabe einer Änderung, welche gespeicherten Berichte, Importe, API-Verbraucher und Workflows darauf verweisen. Testen Sie die Änderung an Kopien repräsentativer Datensätze, bevor Sie sie breit anwenden.
Kontrollierte Werte erfordern besondere Sorgfalt. Die ORM-Dokumentation von Odoo beschreibt einen ondelete-Fallback für erweiterte Selection-Optionen, einschließlich des Setzens eines Werts auf null, einer kaskadierenden Löschung, des Setzens eines Standardwerts, der Zuweisung eines angegebenen Ersatzwerts oder der Ausführung einer benutzerdefinierten Verarbeitung. Dies ist ein nützliches Entscheidungsmuster: Wenn ein Wert außer Betrieb genommen wird, entscheiden Sie ausdrücklich, wie Datensätze behandelt werden, die diesen Wert enthalten. Lassen Sie historische Bedeutung niemals zufällig entstehen. Siehe die Odoo-Dokumentation zur ORM API: https://www.odoo.com/documentation/19.0/developer/reference/backend/orm.html.
- Benennen Sie ein unkritisches Testfeld um und prüfen Sie Berichte, Exporte und Integrationen.
- Versuchen Sie eine Änderung des Feldtyps mit repräsentativen bestehenden Werten.
- Nehmen Sie einen kontrollierten Wert außer Betrieb und überprüfen Sie die Behandlung bestehender Datensätze.
- Dokumentieren Sie für ausgemusterte Werte einen genehmigten Ersatzwert, null oder einen anderen Aufbewahrungsansatz.
- Prüfen Sie, ob finalisierte Datensätze eine strengere Änderungskontrolle erfordern.
- Führen Sie Aufzeichnungen über Schemaentscheidungen und deren Gültigkeitsdaten.
Häufige Fragen
Was ist der wichtigste Test bei der Bewertung benutzerdefinierter Felder?
Erstellen Sie ein realistisches Datensatzmodell und verfolgen Sie es durch den vollständigen Lebenszyklus: Erfassung, Validierung, Workflow, Berechtigungen, Suche, Berichterstattung, Export, Import und jede erforderliche API-Integration. Ein Feld, das nur in einem Formular funktioniert, hat noch nicht bewiesen, dass es betrieblich nützlich ist.
Sollte jede benutzerdefinierte Kategorie eine Auswahlliste oder ein kontrollierter Wert sein?
Nein. Verwenden Sie kontrollierte Werte, wenn Konsistenz für Filterung, Berichterstattung, Automatisierung oder Governance erforderlich ist. Verwenden Sie Freitext, wenn sinnvolle Variationen erwartet werden und nicht in eine künstliche Liste gezwungen werden sollten. Wenn der Wert in Wirklichkeit ein anderes gepflegtes Geschäftsobjekt ist, testen Sie eine Beziehung statt einer Auswahlliste.
Warum sollten wir API-Zugriffe auf eingeschränkte Felder testen?
Ein Feld in einer Benutzeroberfläche auszublenden, ist kein ausreichender Nachweis dafür, dass die zugrunde liegenden Daten geschützt sind. Testen Sie einen eingeschränkten Nutzer über jeden unterstützten Zugriffsweg, den Sie verwenden möchten, einschließlich APIs, Berichterstattung, Exporten und Importen, um zu prüfen, dass Zugriffskontrollen durchgesetzt werden.
Was sollten wir bei einer Migration erhalten?
Bewahren Sie stabile Datensatzkennungen, wenn die Anwendung diese für Aktualisierungen verwendet, ordnen Sie Beziehungen bewusst zu und testen Sie Anhänge und wiederkehrende untergeordnete Zeilen getrennt. Die ERPNext-Dokumentation besagt beispielsweise, dass Aktualisierungen die exportierte ID-Spalte verwenden und dass das Entfernen einer Child-Table-Zeile aus einer Aktualisierungsdatei als beabsichtigte Löschung behandelt wird. Ihre Zielanwendung kann davon abweichen; erproben Sie daher ihr tatsächliches Verhalten. Siehe die ERPNext-Dokumentation zu Data Import: https://docs.frappe.io/erpnext/data-import.
Wann ist eine konfigurierbare Anwendung die falsche Wahl?
Wählen Sie ein speziell entwickeltes System oder eine individuelle Entwicklung, wenn Ihr Kernprozess von komplexen fachlichen Regeln, spezialisierten Berechnungen, ungewöhnlich strengen regulatorischen Kontrollen, einer Verarbeitung von Beziehungen mit hohem Volumen oder einem Datenmodell abhängt, das sich mit den unterstützten Strukturen der Anwendung nicht sauber abbilden und verwalten lässt. Konfiguration sollte das Betriebsrisiko senken, nicht eine grundlegende Fehlanpassung verbergen.
Quellen und weiterführende Literatur
- Field Types — Frappe Framework
- DocField — Frappe Framework
- Child / Table DocType — Frappe Framework
- Users and Permissions — Frappe Framework
- REST API — Frappe Framework
- List — Frappe Framework
- Query Report — Frappe Framework
- Data Import — ERPNext
- Allow on Submit — Frappe Framework
- ORM API — Odoo