21.08.2026

Fehlersuche macht Spaß: Wie zwei kleine Edge Cases bei TYPO3 und Odoo zu echter Detektivarbeit wurden

TYPO3

Ein Formular zeigt sich plötzlich von seiner geheimnisvollen Seite: Ein Nutzer kann sich nicht anmelden und landet immer wieder bei einem leeren Formular. Ein anderer schafft die Anmeldung, aber sein Datensatz landet ohne E-Mail-Adresse in Odoo, obwohl das Feld eigentlich Pflicht ist.

Was zunächst nach zwei kleinen Fehlern klingt, entwickelt sich bei der Anbindung einer TYPO3-Seite an Odoo schnell zu einer kleinen Detektivgeschichte. Die Anmeldung zu einem Congress läuft über TYPO3. Die eingegebenen Daten werden anschließend an Odoo übergeben. Eigentlich ein überschaubarer Prozess. Bis zwei Fälle auftauchen, die sich nicht so verhalten, wie sie sollten.

Für Laien klingt das vielleicht nach einem Fall für den klassischen Satz: „Dann schaut doch mal in den Code.“ In der Praxis reicht das selten. Gerade bei solchen Fehlern muss man verschiedene Systeme, Daten, Prüfungen und Nutzeraktionen zusammendenken. Und manchmal liegt die Ursache an einer Stelle, an der man sie zunächst überhaupt nicht erwartet.

Die Ausgangslage: Zwei Nutzer, zwei merkwürdige Fehler

Der erste Nutzer wollte sich für den Congress registrieren. Er füllte das Formular aus und schickte es ab. Statt einer erfolgreichen Anmeldung landete er wieder bei einem leeren Formular.

Der zweite Nutzer hatte scheinbar mehr Glück. Seine Anmeldung wurde verarbeitet. Allerdings fehlte anschließend seine E-Mail-Adresse in Odoo. Das war besonders auffällig, weil die E-Mail-Adresse im TYPO3-Formular als Pflichtfeld definiert war.

Damit standen zwei Fragen im Raum:

• Warum konnte der erste Nutzer das Formular nicht erfolgreich absenden?
• Wie konnte beim zweiten Nutzer ein Datensatz ohne E-Mail-Adresse entstehen, obwohl das Feld verpflichtend war?

Beide Fälle hatten eine Gemeinsamkeit: Sie ließen sich nicht einfach durch einen offensichtlichen Programmierfehler erklären.

Die erste Spur: Code analysieren und den Fehler reproduzieren

Der erste Schritt war eine Analyse des vorhandenen Codes. Dabei wurde unter anderem KI zur Unterstützung eingesetzt. Das kann bei der Fehlersuche hilfreich sein, ersetzt aber nicht das eigentliche Testen. Denn ein Stück Code kann völlig plausibel aussehen und sich trotzdem in einer bestimmten Situation anders verhalten.

Deshalb wurde anschließend nicht nur allgemein getestet. Die Anmeldung wurde mit exakt den Daten wiederholt, die der betroffene Nutzer verwendet hatte.

Das war der entscheidende Moment. Der Fehler ließ sich reproduzieren.

Das Formular konnte tatsächlich nicht abgeschickt werden. Allerdings lag die Ursache nicht dort, wo man sie zunächst vermutet hätte.

Fall 1: Das Formular war nicht kaputt, aber die Fehlermeldung war praktisch unsichtbar

Ein Feld im Formular war falsch ausgefüllt. TYPO3 erkannte das und verhinderte den Versand. Technisch funktionierte die Validierung also genau so, wie sie sollte.

Das Problem lag an einer anderen Stelle: Die Fehlermeldung war kaum noch zu erkennen.

Durch redaktionelle Änderungen an den Texten und eine ungünstige Darstellung im Formular ging der Hinweis unter. Der Nutzer sah deshalb nicht: „Dieses Feld ist falsch ausgefüllt.“ Er sah im Wesentlichen nur ein Formular, das nach dem Absenden wieder da war.

Aus Sicht des Nutzers war das ein ziemlich guter Weg, ihn ratlos zurückzulassen.

Die Lösung war vergleichsweise einfach. Das Layout wurde angepasst, sodass Fehlermeldungen wieder an der richtigen Stelle und ausreichend auffällig angezeigt werden.

Damit war allerdings nur das sichtbare Problem gelöst. Bei der Analyse stellte sich heraus, dass hinter dieser Fehlermeldung noch eine wesentlich interessantere Geschichte steckte.

Wenn TYPO3 und Odoo bei derselben E-Mail-Adresse unterschiedlicher Meinung sind

TYPO3 prüft bei der Anmeldung über einen API-Aufruf, ob die eingegebene E-Mail-Adresse bereits in Odoo vorhanden ist. Nach dem Absenden prüft Odoo die Daten zusätzlich noch einmal selbst.

Das klingt zunächst vernünftig. Zwei Prüfungen, doppelte Sicherheit.

Nur prüften die beiden Systeme nicht auf dieselbe Weise.

TYPO3 führte den Vergleich case-sensitiv durch. Dabei wird zwischen Groß- und Kleinschreibung unterschieden. Bei E-Mail-Adressen ist das für die praktische Behandlung von Adressen problematisch. Odoo verwendete dagegen einen Like-Vergleich.

Damit konnte eine Situation entstehen, in der TYPO3 eine E-Mail-Adresse als nicht vorhanden betrachtete, während Odoo beim anschließenden eigenen Abgleich zu einem anderen Ergebnis kam.

Warum war dieser Fehler vorher nicht aufgefallen?

Weil dafür mehrere Bedingungen gleichzeitig erfüllt sein mussten. Die E-Mail-Adresse musste bereits in Odoo vorhanden sein. Gleichzeitig musste die Schreibweise bei der Eingabe so abweichen, dass die unterschiedliche Vergleichslogik relevant wurde.

Da E-Mail-Adressen in der Regel mit Kleinbuchstaben eingegeben werden, trat dieser Fall im normalen Betrieb praktisch nicht auf. Erst die Kombination aus vorhandenen Daten, einer bestimmten Schreibweise und dem Ablauf der beiden Prüfungen machte den Fehler sichtbar.

Ein klassischer Edge Case also.

Der Fehler wurde behoben, indem die Prüfung so angepasst wurde, dass die Systeme bei der Bewertung der E-Mail-Adresse konsistent arbeiten.

Fall 2: Wie kann ein Pflichtfeld plötzlich leer sein?

Der zweite Fall war deutlich hartnäckiger.

Ein Nutzer war offenbar durch den Anmeldeprozess gekommen, obwohl anschließend keine valide E-Mail-Adresse im Datensatz vorhanden war. Das passte nicht zum Verhalten des Formulars. Die E-Mail-Adresse war als Pflichtfeld definiert.

Also begann die Suche von vorne.

Es wurde getestet, getestet und noch einmal getestet. Verschiedene Szenarien wurden durchgespielt. Trotzdem ließ sich zunächst nicht nachvollziehen, wie ein Datensatz ohne gültige E-Mail-Adresse entstehen konnte.

Genau an diesem Punkt wird Fehlersuche interessant. Wenn ein Fehler sich nicht reproduzieren lässt, hilft es oft nicht, einfach noch mehr Varianten auszuprobieren. Man muss den Ablauf selbst zerlegen.

Der entscheidende Hinweis lag im Umgang mit bestehenden Nutzern

Eine manuelle Analyse des Codes zusammen mit den vom Nutzer bereitgestellten Daten führte schließlich auf die richtige Spur.

Das Formular behandelt nämlich zwei unterschiedliche Fälle:

• Ein Nutzer existiert bereits in Odoo.
• Ein Nutzer ist in Odoo noch nicht vorhanden.

Bei einem bereits vorhandenen Nutzer werden dessen Daten aus Odoo geladen, wenn während der Anmeldung ein Fehler auftritt. Das ist sinnvoll, weil der Nutzer seine bereits bekannten Daten nicht erneut eingeben soll.

Die E-Mail-Adresse ist dabei eine Besonderheit. Sie darf nicht einfach geändert werden. Deshalb wird das entsprechende Feld als readonly dargestellt.

Bei einem neuen Nutzer sollte dagegen etwas anderes passieren: Die bereits im Formular eingegebenen Daten sollten erhalten bleiben, damit der Nutzer nach einem Fehler nicht alles noch einmal eingeben muss.

Und genau hier kamen zwei Fehler zusammen.

Bug Nummer eins: Die eingegebenen Formulardaten gingen verloren

Bei einem neuen Nutzer gingen die bereits eingegebenen Formulardaten durch einen Fehler verloren, sobald eine Validierung oder Verarbeitung scheiterte.

Der Nutzer musste das Formular deshalb erneut ausfüllen.

Das war zunächst schon ärgerlich, erklärte aber noch nicht, wie die E-Mail-Adresse fehlen konnte.

Bug Nummer zwei: Ein neuer Nutzer wurde nicht mehr als neuer Nutzer erkannt

Unter bestimmten Voraussetzungen wurde ein Nutzer anschließend nicht mehr korrekt als neu erkannt.

Das führte zu einer ziemlich ungünstigen Kombination: Der Nutzer sah ein leeres Formular. Gleichzeitig wurde das E-Mail-Feld als readonly behandelt, weil das System davon ausging, dass bereits ein bestehender Nutzer vorlag.

Damit war der Nutzer in einer Sackgasse.

Er konnte die E-Mail-Adresse nicht eintragen. Das Feld wurde gleichzeitig nicht mehr auf die gleiche Weise validiert, weil es als nicht editierbares Feld behandelt wurde. Am Ende konnte das Formular mit einem leeren E-Mail-Feld abgesendet werden.

Auf dem Papier wirkt der Fehler fast absurd. In der tatsächlichen Anwendung war er allerdings nur unter einer sehr speziellen Kombination von Umständen möglich.

Der Nutzer musste unter anderem in einen bestimmten Zustand geraten, bei der Verarbeitung musste ein Fehler auftreten und anschließend musste die Erkennung des Datensatzes in einen anderen Zustand wechseln. Genau deshalb war der Fehler bei normalen Tests kaum zu finden.

Warum Edge Cases bei der Fehlersuche besonders interessant sind

Ein Edge Case ist kein exotischer Fehler, den man einfach ignorieren kann. Er entsteht häufig dort, wo mehrere eigentlich funktionierende Abläufe miteinander kombiniert werden.

Genau das war bei der TYPO3-Odoo-Anbindung der Fall.

Die einzelnen Bestandteile funktionierten für sich betrachtet plausibel:

• TYPO3 validiert Formulareingaben.
• TYPO3 fragt über die Odoo-API nach vorhandenen Datensätzen.
• Odoo prüft die übergebenen Daten erneut.
• Bestehende Nutzer bekommen ihre Daten aus Odoo.
• Neue Nutzer können ihre Daten im Formular eingeben.
• Pflichtfelder werden validiert.

Der Fehler entstand nicht deshalb, weil einer dieser Punkte grundsätzlich falsch war. Er entstand durch das Zusammenspiel mehrerer Zustände.

Das macht solche Fehler so schwierig. Man muss nicht nur fragen: „Was macht dieser Code?“ Man muss fragen: „Was passiert, wenn Nutzer A bereits in Odoo existiert, Nutzer B noch nicht existiert, das Formular einen Fehler enthält und anschließend ein bestimmter Verarbeitungsschritt erneut ausgeführt wird?“

Das ist der Moment, in dem Fehlersuche tatsächlich etwas von Detektivarbeit bekommt.

Praxisbeispiel: Warum ein normaler Test nicht ausreicht

Angenommen, ein neuer Congress-Teilnehmer füllt das Formular korrekt aus und sendet es ab. Der Datensatz wird angelegt. Alles funktioniert.

Der nächste Test verwendet einen bestehenden Odoo-Kontakt. Auch dieser Fall funktioniert.

Damit könnte man die Integration zunächst als fehlerfrei betrachten.

Interessant wird es erst, wenn man einen Fehler in den Ablauf einbaut: Ein Nutzer gibt beispielsweise ein Feld falsch ein. Das System verarbeitet den Fehler, lädt Daten erneut, prüft den Nutzerstatus und entscheidet anschließend, ob es sich um einen bestehenden oder neuen Datensatz handelt.

Genau solche Übergänge zwischen Zuständen sind anfällig für Fehler.

Bei der zweiten Problematik waren sogar mehrere dieser Bedingungen notwendig. Deshalb konnte die Anwendung im Alltag über lange Zeit problemlos funktionieren, bevor ein einzelner Nutzer genau in die falsche Kombination geriet.

Was aus der Fehlersuche für TYPO3- und Odoo-Projekte bleibt

Die beiden Fehler zeigen vor allem, dass eine funktionierende Standardstrecke wenig über die Qualität einer komplexeren Integration aussagt.

Bei einer Verbindung zwischen TYPO3 und Odoo sollte deshalb nicht nur der erfolgreiche Ablauf getestet werden. Auch Zustandswechsel und Fehlerfälle gehören in die Prüfung.

• Was passiert, wenn ein Nutzer bereits im Zielsystem existiert?
• Was passiert, wenn er noch nicht existiert?
• Was passiert nach einem Validierungsfehler?
• Bleiben bereits eingegebene Formulardaten erhalten?
• Welche Felder werden nach einem Fehler wieder editierbar?
• Prüfen alle beteiligten Systeme Daten nach denselben Regeln?
• Was passiert, wenn ein API-Aufruf erfolgreich ist, die anschließende Prüfung aber scheitert?
• Kann ein Nutzer nach einem Fehler noch erkennen, was er ändern muss?

Gerade der letzte Punkt wird bei technischen Analysen gerne unterschätzt. Ein System kann technisch korrekt reagieren und trotzdem eine schlechte Nutzererfahrung erzeugen. Wenn eine Fehlermeldung nicht sichtbar ist, hilft die beste Validierung wenig.

Fazit: Gute Fehlersuche beginnt oft mit den falschen Fragen

Bei beiden Fehlern wäre die naheliegende Frage gewesen: „Wo ist der Bug?“

Hilfreicher waren andere Fragen: Was genau hat der Nutzer gemacht? Welche Daten wurden verwendet? Welchen Zustand hatte der Datensatz zu diesem Zeitpunkt? Was prüft TYPO3? Was prüft Odoo? Was passiert nach einem Fehler? Und welche Annahme trifft das System an dieser Stelle über den Nutzer?

So wurden aus zwei scheinbar kleinen Problemen mehrere zusammenhängende Ursachen.

Der erste Fehler führte über eine schlecht sichtbare Fehlermeldung zu einer tieferen Unstimmigkeit bei der E-Mail-Prüfung. Der zweite Fehler entstand durch das Zusammenspiel von Formulardaten, Nutzererkennung, readonly-Feldern und einer fehlerhaften Verarbeitung nach einem Fehlerfall.

Beide Probleme waren Edge Cases. Beide waren schwer zu reproduzieren. Und beide hätten sich mit einem reinen Blick auf den erfolgreichen Standardablauf wahrscheinlich nicht finden lassen.

Genau deshalb macht Fehlersuche Spaß: Man beginnt mit einem merkwürdigen Verhalten und arbeitet sich Schritt für Schritt zur Ursache vor. Am Ende geht es nicht darum, irgendwo eine Zeile Code zu ändern. Es geht darum, zu verstehen, warum ein System in einer bestimmten Situation eine Entscheidung trifft, die aus Nutzersicht keinen Sinn ergibt.

Und wenn TYPO3 und Odoo dabei einmal unterschiedlicher Meinung über eine E-Mail-Adresse sind, fühlt sich das tatsächlich ein bisschen wie Detektivarbeit an.

Bugfixing anfragen

FAQ

Was ist ein Edge Case bei einer Webanwendung?

Ein Edge Case ist eine seltene Situation, die nur unter bestimmten Voraussetzungen auftritt. Häufig müssen dafür mehrere Zustände oder Bedingungen zusammenkommen. Solche Fälle können lange unentdeckt bleiben, obwohl die Anwendung im normalen Betrieb problemlos funktioniert.

Warum sind Fehler bei TYPO3-Odoo-Integrationen schwer zu finden?

Weil mehrere Systeme an einem Vorgang beteiligt sind. TYPO3 kann Daten prüfen, an Odoo übertragen und anschließend mit einer Antwort von Odoo weiterarbeiten. Zusätzlich kann Odoo eigene Prüfungen durchführen. Ein Fehler kann deshalb durch das Zusammenspiel der Systeme entstehen und nicht durch einen einzelnen offensichtlichen Fehler.

Warum sollte man einen Fehler mit den Originaldaten des Nutzers reproduzieren?

Weil kleine Unterschiede bei den Eingabedaten entscheidend sein können. Ein Fehler tritt möglicherweise nur bei einer bestimmten E-Mail-Adresse, Schreibweise oder Kombination von Feldern auf. Die Originaldaten erhöhen die Wahrscheinlichkeit, genau den Zustand zu reproduzieren, in dem der Fehler tatsächlich entstanden ist.

Warum reicht eine Codeanalyse bei der Fehlersuche nicht aus?

Codeanalyse zeigt, was ein Programm laut seiner Logik tun sollte. Sie zeigt nicht automatisch, wie sich das gesamte System mit echten Daten und mehreren aufeinanderfolgenden Zuständen verhält. Deshalb sollten Codeanalyse und reproduzierbare Tests zusammen eingesetzt werden.

Warum kann eine Pflichtfeldprüfung trotzdem zu einem leeren Feld führen?

Eine Pflichtfeldprüfung schützt nur dann zuverlässig, wenn das Feld korrekt in den Validierungsprozess eingebunden bleibt. Wird ein Feld beispielsweise aufgrund eines falschen Zustands als readonly behandelt und anschließend nicht mehr validiert, kann ein Fehler in der Programmlogik die ursprüngliche Schutzfunktion umgehen.

Was sollte bei Formularen nach einem Fehler passieren?

Bereits eingegebene Daten sollten möglichst erhalten bleiben. Der Nutzer sollte erkennen können, welches Feld fehlerhaft ist, und dieses Feld anschließend bearbeiten können. Ein Formular, das nach einem Fehler leer zurückkommt, erhöht unnötig die Abbruchwahrscheinlichkeit.

Warum ist eine gute Fehlermeldung technisch relevant?

Eine Fehlermeldung ist Teil des Bedienkonzepts. Wenn das System einen Fehler erkennt, der Nutzer ihn aber nicht wahrnimmt, bleibt das Problem bestehen. Die technische Validierung kann also korrekt funktionieren, während der tatsächliche Ablauf für den Nutzer trotzdem fehlerhaft wirkt.

Wie testet man Edge Cases bei einer TYPO3-Odoo-Anbindung?

Neben erfolgreichen Standardfällen sollten verschiedene Nutzerzustände und Fehlerabläufe geprüft werden. Dazu gehören bestehende und neue Nutzer, fehlerhafte Eingaben, wiederholte Übermittlungen, API-Fehler, unterschiedliche Schreibweisen von Daten und der Zustand des Formulars nach einer fehlgeschlagenen Verarbeitung.

Was ist bei der Fehlersuche wichtiger: Code oder Nutzerverhalten?

Beides muss zusammen betrachtet werden. Der Code bestimmt, was das System tut. Das Nutzerverhalten zeigt, unter welchen Bedingungen diese Logik tatsächlich ausgeführt wird. Gerade bei seltenen Fehlern liefert die Kombination aus realen Nutzerdaten, Ablauf und Codeanalyse häufig den entscheidenden Hinweis.

Bugfixing anfragen