Wenn Sie sich schon länger mit Odoo beschäftigen, ist Ihnen das Wort „Context“ sicher begegnet – in Felddefinitionen, in XML‑Views oder im Python‑Code. Für viele wirkt es wie eine unsichtbare Steuerung: solange alles klappt, fällt es kaum auf; sobald etwas unerwartet passiert, ist Context oft die Ursache.
Context beeinflusst unmittelbar, wie sich Ihre Modelle verhalten: welche Felder vorausgefüllt werden, welche Datensätze angezeigt werden, und wie berechnete Felder entscheiden, welchen Wert sie liefern. Ob Sie nur eine kleine Anpassung vornehmen oder ein komplettes Modul entwickeln – ein sauberer Umgang mit Context spart später viel Fehler‑ und Testaufwand.
Dieser Beitrag erklärt kompakt, was Context ist, wie er sich durch Odoo bewegt und wie Sie ihn in echten Projekten sicher nutzen können.
Was bedeutet „Context“ in Odoo?
In Odoo ist Context keine eigene Feldklasse, sondern ein Python‑Dictionary, das jeder Anfrage und jedem Methodenaufruf beiliegt. Sie finden kein fields.Context() – stattdessen wirkt dieses Dictionary als Zusatzinformation, die das Verhalten von Feldern und Methoden verändert.
Man kann sich Context als versteckte Bedienungsanleitung vorstellen, die mitläuft: Sie sagt Odoo etwa, welches Standard‑Feld einzutragen ist, ob archivierte Datensätze angezeigt werden sollen, in welcher Sprache Texte berechnet werden oder welche Filter beim Auswählen von Relationen gelten sollen.
Wo Context auftaucht
In Odoo begegnet Ihnen Context im Wesentlichen an drei Stellen im Datenmodell:
- Auf Python‑Felddefinitionen: Relationale Felder wie Many2one, One2many und Many2many akzeptieren einen context‑Parameter.
- In XML‑Views: Feldtags in Formularen, Listen oder Kanban können ein context‑Attribut tragen.
- In der ORM‑Umgebung: In Python lesen Sie das aktuelle Dictionary über self.env.context und erzeugen veränderte Umgebungen mit self.with_context(...).
Überall erfüllt Context dieselbe Aufgabe: zusätzliche Informationen zu transportieren, die das Laufzeitverhalten von Feldern und Records beeinflussen.
Wie Context im Odoo‑Datenmodell wirkt
Context begleitet den kompletten Ablauf – vom Öffnen eines Formulars bis zum Speichern eines Datensatzes. Im Alltag spielen dabei einige Mechanismen eine besonders große Rolle.
Vorausfüllung über default_*
Ein sehr verbreitetes Muster sind Schlüssel, die mit default_ beginnen. Solche Werte füllen das entsprechende Feld automatisch, wenn ein neuer Datensatz angelegt wird.
Beispiel: Öffnet ein Button die Auftragsanlage und übergibt im Context {"default_partner_id": 42}, steht das Kundenfeld beim Öffnen bereits auf dem Partner mit der ID 42. So entstehen intelligente Flows ohne zusätzliche Python‑Logik.
Dieses Muster ist in vielen Odoo‑Projekten Standard, um Navigation und Datenerfassung zu vereinfachen.
Context an relationalen Feldern
Beim Definieren von Many2one/One2many/Many2many können Sie ein context‑Dictionary angeben. Dieses wird genutzt, wenn über das Feld neue Beziehungen erstellt oder im Popup ausgewählt werden.
Praktisch heißt das: Ein Many2one auf res.partner mit context={"default_is_company": True} sorgt dafür, dass beim direkten Anlegen eines neuen Partners über dieses Feld die Checkbox „Firma“ vorausgewählt ist – eine sanfte Unterstützung für Benutzer, keine harte Vorgabe.
Context in XML‑Views
In XML können Sie mit dem context‑Attribut dynamische Ausdrücke nutzen und Felder anderer Datensätze referenzieren.
So bauen Sie Formulare, in denen das Verhalten eines Feldes von einem anderen Feld abhängt – ein zentraler Trick für smarte Anpassungen ohne zusätzlichen Python‑Code.
Context in Python lesen und ändern
Innerhalb von Model‑Methoden greifen Sie auf das aktuelle Dictionary via self.env.context zu; das zeigt den Context zum Zeitpunkt des Aufrufs.
Um lokal eine veränderte Umgebung zu verwenden, nutzen Sie self.with_context(key=value). Das erzeugt einen neuen Recordset mit kopiertem, aber geänderten Context – ein nicht‑destruktives, sicheres Muster.
Wichtige eingebaute Kontext‑Schlüssel
Odoo definiert einige reservierte Keys, die bestimmtes Verhalten auslösen und in vielen Fällen genutzt werden können statt eigener Logik.
- lang – steuert die Sprache für übersetzte Felder.
- active_test – auf False gesetzt, zeigt auch archivierte Datensätze bei Suchvorgängen.
- no_recompute – verhindert das automatische Neuberechnen gespeicherter Compute‑Felder.
- mail_notrack – deaktiviert Chatter‑Tracking bei Schreiboperationen.
- allowed_company_ids – begrenzt Sichtbarkeit in Multi‑Company‑Setups.
- bin_size – liefert Dateigrößen statt Binärdaten bei Binary‑Feldern.
Diese Standard‑Keys gehören in jede Praxisanleitung für Entwickler, weil sie oft genug genutzte Steuerhebel bereitstellen.
Praxisnahe Anwendungsbeispiele
Context löst nicht nur Programmieraufgaben, sondern echte Workflow‑Anforderungen. Fünf typische Beispiele aus Projekten zeigen das sehr konkret.
1. CRM: Vorbelegung des Vertriebsteams bei neuen Leads
In einer Team‑Kanban‑Ansicht erwartet die Vertriebsmitarbeiterin beim Klick auf „Neu“, dass der Lead ihrem Team zugewiesen wird. Übergibt die Aktion default_team_id im Context, öffnet das Formular bereits mit dem passenden Team – weniger Klicks, weniger Fehler.
2. Verkauf: Standard‑Preisliste je Kundengruppe
Beim Angebotserstellen aus einer bestimmten Kundensegment‑Ansicht kann die passende Pricelist per Context default_pricelist_id gesetzt werden. So wird der richtige Preis vorgeschlagen, ohne den Verkaufskräften die Wahl zu nehmen.
3. Lager: Eingrenzung von Standorten in Transferformularen
Im Wareneingang kann das Feld für die Quell‑Location per Context so eingeschränkt werden, dass nur Standorte eines bestimmten Lagers angezeigt werden. Das reduziert Fehlannahmen in Multi‑Warehouse‑Umgebungen.
4. Buchhaltung: Rechnungspositionen in der Kundensprache
Mit dem Context‑Key lang lassen sich Beschreibungstexte in der bevorzugten Sprache des Kunden anzeigen — beispielsweise französische Produktbeschreibungen für einen französischen Empfänger, obwohl das System intern auf Englisch arbeitet.
5. Eigene Modelle: Archivierte Produkte in speziellen Ansichten anzeigen
Eine Betriebsabteilung möchte deaktivierte Produkte gemeinsam mit aktiven sehen. Eine spezifische List‑View kann active_test: False im Action‑Context haben, so dass nur diese Ansicht archivierte Einträge zeigt, ohne die globale Logik zu ändern.
Context für Felder anlegen und anpassen
Context können Sie auf zwei Wegen setzen: per Odoo Studio ohne Code oder per Python/XML für volle Flexibilität – beides gehört zu soliden technischen Anleitungen.
Mit Odoo Studio arbeiten
Studio ermöglicht einfache Anpassungen: Für relationale Felder gibt es eine Option, um Default‑Werte zu konfigurieren, die beim Anlegen über das Feld gesetzt werden.
Das ist ideal für simple Fälle wie Standard‑Firma, Team oder verantwortliche Person. Allerdings sind Studio‑Einstellungen bewusst beschränkt – für dynamische, feldabhängige Context‑Werte brauchen Sie XML/Python.
Wenn Sie Studio verwenden, bedenken Sie: Die Context‑Angaben werden im View gespeichert. Spätere technische Erweiterungen derselben View müssen diese Studio‑Konfiguration berücksichtigen, damit sich Einstellungen nicht gegenseitig ausstechen.
Context in Python‑Feldern definieren
In einem Modul fügen Sie Context direkt in die Felddefinition ein. Bei Many2one nimmt der context‑Parameter ein statisches Dictionary an.
Solche statischen Werte gelten bei jeder Nutzung des Feldes und ändern sich nicht dynamisch mit anderen Feldwerten. Reagierende Context‑Logik verlagern Sie besser in die View‑Ebene.
Context in XML‑Views definieren
Im View‑XML übergeben Sie Context als auswertbaren String; Sie können dabei aktuelle Feldwerte, uid, active_id und weitere Variablen referenzieren.
Dadurch ist View‑Context deutlich flexibler als Feld‑Context und das Mittel der Wahl, wenn Verhalten von Feldern von anderen Eingaben abhängen soll – so wirken Ihre Anpassungen für Anwender nativer.
Context per Window‑Action übergeben
Auch ir.actions.act_window trägt ein Context‑Feld. Aktionen, Menüs und Buttons legen hiermit die Context‑Defaults fest, die beim Öffnen einer View in die Session übernommen werden.
Für viele Navigation‑spezifische Defaults (wie das CRM‑Beispiel mit dem Team) ist das die sauberste Lösung: Das Default‑Verhalten lebt auf der Aktion, nicht im Modell, und ist so kontextspezifisch änderbar.
Empfohlene Vorgehensweisen
Ein paar einfache Regeln machen den Umgang mit Context deutlich verlässlicher – egal ob Modulentwicklung oder schnelle Anpassung.
- Nutzen Sie Context als Empfehlung, nicht als Zwang. Defaults sollen Benutzer leiten; harte Einschränkungen gehören in Domains oder Onchange‑/Constraint‑Logik.
- Platzieren Sie dynamischen Context in Views, nicht in Felddefinitionen. Feld‑Context ist statisch und eignet sich kaum für kontextabhängige Logik.
- Verwenden Sie with_context() statt direktes Mutieren von env.context. So bleibt die Umgebung unverändert und Sie arbeiten funktional und sicher.
- Geben Sie nur mit, was nötig ist. Context‑Keys sammeln sich entlang des Aufrufstapels; unnötige Schlüssel führen leicht zu Seiteneffekten.
- Setzen Sie Context auch für Steuerflags. Ein boolescher Key wie from_wizard: True ist ein gängiges Muster, um Methoden oder Berechnungen kontextabhängig unterschiedlich laufen zu lassen, ohne Modellfelder zu verunreinigen.
- Dokumentieren Sie eigene Context‑Keys im Modul. Da sie unsichtbar sind, hilft ein Kommentar oder Docstring später beim Verständnis und bei der Wartung.
Häufige Fehlerquellen
Fehler im Umgang mit Context sind oft schwer zu finden, weil die Steuerinformationen nicht direkt in der Oberfläche sichtbar sind. Folgende Fallen treten regelmäßig auf.
Default_* nicht mit Pflichtwerten verwechseln
Ein per Context gesetzter Default wirkt nur beim Anlegen über ein Formular. Wenn Datensätze programmgesteuert ohne passenden Context erstellt werden, fehlen diese Defaults. Erwarten Sie also nicht, dass default_* wie ein Feld‑Default auf Schema‑Ebene wirkt.
Context‑Dictionary direkt verändern
Das direkte Ändern von self.env.context beeinflusst die gemeinsame Umgebung und kann anderen Code innerhalb derselben Transaktion Probleme machen. Nutzen Sie stattdessen self.with_context(...) für Kopien mit Änderungen.
Zu viel in den Context packen
Jeder Key reist mit und kann Logikpfade in anderen Methoden auslösen. Halten Sie den Context schlank und auf die aktuelle Operation beschränkt.
active_test vergessen bei Archivsuche
Standardmäßig filtert search() archivierte Records heraus. Wenn Sie mit deaktivierten Einträgen arbeiten müssen, setzen Sie explizit active_test: False im Context – sonst fehlen wichtige Ergebnisse.
Konflikte zwischen Studio und technischem Code
Wenn Studio bereits Context auf einer View gesetzt hat und Sie später via XML dieselbe View erweitern, können sich die Context‑Angaben überschreiben. Prüfen Sie vor Änderungen bestehende View‑Contexts, vor allem wenn Studio‑Felder im Spiel sind.
Fazit
Context ist ein kraftvolles, aber unsichtbares Werkzeug in Odoo. Sobald Sie seine Wege durch Felddefinitionen, Views und die ORM‑Umgebung kennen, gewinnen Sie deutlich mehr Kontrolle über die Modell‑ und UI‑Logik.
Die wichtigsten Punkte kurz zusammengefasst: Nutzen Sie default_* zur sinnvollen Vorbelegung, legen Sie dynamische Context‑Logik in Views ab, verwenden Sie with_context() statt direkter Änderungen und behalten Sie Context schlank, damit er nicht unbeabsichtigt andere Teile beeinflusst.
Ob beim Lernprogramm zu Feldern, beim Entwickeln eines Moduls oder beim Debugging — ein klares Verständnis des Context ist fast immer ein Teil der Lösung.
Bei Dasolo unterstützen wir Unternehmen dabei, Odoo auf ihre konkreten Abläufe zuzuschneiden, anzupassen und zu optimieren. Wenn Sie bei einer Anpassung mit Context unsicher sind oder Ihre Implementierung durchsprechen möchten, helfen wir gern weiter.
Kontaktieren Sie unser Team über die Kontaktseite und erzählen Sie uns, woran Sie arbeiten. Wir begleiten Firmen jeder Größe dabei, Odoo so nutzerfreundlich und prozesssicher wie möglich einzusetzen.