If you have spent any time working with the Odoo ORM or customizing views, you have almost certainly seen the word context pop up. It appears on field definitions, in XML view attributes, and throughout Odoo's Python code. Yet for many developers and consultants, it remains one of those things that just works until it doesn't.
Understanding context fields in Odoo is not just an academic exercise. It directly affects how your data model behaves, how forms pre-fill values, how records are filtered, and how computed fields decide what to return. Whether you are doing a simple odoo customization or building a full module, getting context right saves a lot of debugging time.
This guide breaks down what context is, how it flows through the Odoo framework, and how to use it confidently in real projects.
What is Context in Odoo
Context in Odoo is a Python dictionary that travels alongside every request, every method call, and every record operation. It is not a field type in the traditional sense. You will not find fields.Context() in the Odoo ORM. Instead, context is a mechanism that modifies how fields behave.
Think of it as a set of invisible instructions passed along with your data. Those instructions tell Odoo things like: pre-fill this field with a default value, show archived records too, compute this field using a different language, or apply this domain when showing the related records picker.
Where Does Context Appear
You will encounter context in three main places across the Odoo data model:
- On field definitions in Python: The
contextparameter on relational fields like Many2one, One2many, and Many2many. - In XML view attributes: The
contextattribute on<field>tags in form, list, and kanban views. - In the ORM environment: Accessible via
self.env.contextin Python code, and modifiable withself.with_context(key=value).
In all three cases, context is doing the same fundamental thing: it carries extra information that shapes how a field or a record behaves at runtime.
How Context Works in the Odoo Data Model
Context flows through the Odoo request lifecycle from the moment a user opens a form to the moment a record is saved. Here is how the key mechanisms work in practice.
Default Values with default_*
One of the most commonly used context patterns is default_field_name. When you pass a key starting with default_, Odoo uses it to pre-fill a field when a new record is created.
For example, if a button opens a new sale order form and passes {"default_partner_id": 42} in the context, the customer field will already be set to the partner with ID 42. The user sees a pre-filled form without any additional Python logic required.
This pattern is heavily used in Odoo development to create smart navigation flows between records.
The context Attribute on Relational Fields
When you define a Many2one, One2many, or Many2many field in Python, you can pass a context parameter. This context is applied whenever the relational field loads or creates records through its popup or dropdown.
A practical example: a Many2one pointing to res.partner with context={"default_is_company": True} means that if the user creates a new partner directly from that field, the Is a Company checkbox will be pre-checked. You are nudging the user toward the right data without enforcing it.
Context in XML Views
In view XML, the context attribute on a field tag works the same way, but it can be dynamic. You can reference other field values using Odoo's evaluation syntax:
This allows you to build intelligent forms where one field's context depends on the value of another. It is a core technique in odoo customization for creating smart relational behaviors without writing extra Python code.
Reading and Modifying Context in Python
Inside any model method, you can read the current context using self.env.context. This gives you the full dictionary as it was when the method was called.
To run code with a modified context, you use self.with_context(key=value). This returns a new recordset that carries the updated context without changing the original. It is a clean, non-destructive pattern that fits well with Odoo's functional programming style.
Common Built-in Context Keys
Odoo itself uses several reserved context keys that trigger specific behavior across the Odoo framework:
lang: Changes the language used for translated field values.active_test: Set toFalseto include archived records in search results.no_recompute: Prevents stored computed fields from being recalculated.mail_notrack: Disables chatter tracking for a write operation.allowed_company_ids: Controls multi-company record visibility.bin_size: Returns file sizes instead of binary content for Binary fields.
Knowing these built-in keys is part of any solid odoo developer guide because they let you control behavior without writing custom code.
Business Use Cases
Context fields are not just a developer tool. They solve real workflow problems across different business areas. Here are five examples from common Odoo implementations.
1. CRM: Pre-filling the Sales Team on New Leads
A sales manager has a kanban view filtered to her team. When she clicks "New", she expects the lead to be automatically assigned to her team. By passing default_team_id in the action's context, the team field is pre-filled the moment the form opens. No manual selection needed, no wrong team assignments.
2. Sales: Defaulting the Pricelist Based on the Customer Segment
When a salesperson creates a quote from a specific customer category view, the pricelist field can be pre-set using context. The context carries default_pricelist_id based on the category, guiding the salesperson to the right pricing without restricting their choices.
3. Inventory: Filtering Locations in Transfer Forms
In warehouse operations, a transfer form's source location field can use context to restrict the dropdown to only locations belonging to a specific warehouse. This is done by passing a domain via context on the Many2one field, keeping the interface clean and reducing errors in multi-warehouse setups.
4. Accounting: Multi-language Invoice Lines
When generating invoices for international customers, the lang context key forces translated descriptions to appear in the customer's language. An invoice sent to a French customer will show product names and descriptions in French, even if the internal database stores everything in English.
5. Custom Models: Showing Archived Products in a Special View
An operations team needs to review discontinued products alongside active ones. A custom list view passes active_test: False in its action context. Without changing any Python code, all products including archived ones appear in that specific view, while the rest of the interface stays unaffected.
Creating and Customizing Context on Fields
There are two paths to add or modify context on fields in Odoo: using Odoo Studio for no-code adjustments, or writing Python and XML for full technical control. This is a key part of any odoo technical tutorial on field behavior.
Using Odoo Studio
Odoo Studio allows you to modify certain field properties without writing code. For relational fields, Studio exposes a context configuration option where you can set default values that will be applied when a new record is created from that field.
This is useful for straightforward cases: pre-filling a company, a team, a category, or a responsible user. The limitation is that Studio's context support is intentionally simplified. For dynamic context that references other field values, you will need to go the technical route.
When using odoo studio fields, keep in mind that the context you set is stored directly on the view. If you later create a technical customization on the same view, you need to account for existing Studio-defined context to avoid conflicts.
Defining Context on Fields in Python
In a custom module, context is added directly to the field definition. For a Many2one field, the context parameter accepts a static dictionary:
This static context is applied every time the field loads or creates related records. It does not change based on other field values. For a context that reacts to the current record's state, you move the logic to the view level instead.
Defining Context in XML Views
In view XML, the context attribute accepts a string that Odoo evaluates at runtime. You can reference field values, the current user ID (uid), the active record ID (active_id), and other variables:
This makes view-level context much more flexible than field-level context. It is the standard approach in the odoo framework for building forms where one field's behavior depends on another. This is also how you create fields odoo behaviors that feel native and intuitive to end users.
Passing Context via Window Actions
Context can also be set on ir.actions.act_window records. This is how menus and buttons pass context to the views they open. An action's context field contains the dictionary that gets merged into the session context when the view loads.
This is the cleanest way to handle use cases like the CRM sales team example above. The context lives on the action, not on the field definition, which means you can have different defaults in different navigation contexts without touching the model code.
Best Practices
Working with context in Odoo becomes much smoother once you follow a few consistent habits. These apply whether you are building a module or doing a quick odoo customization.
- Use context for suggestions, not enforcement. Context-driven defaults guide users without blocking them. If you need a hard constraint, use a domain or an onchange method instead.
- Put dynamic context in views, not in field definitions. Field-level context is static. If the context needs to reflect the current record's state, the view XML is the right place for it.
- Use with_context() instead of modifying env.context directly. Odoo's environment is designed to be immutable within a call. Always create a new environment with
with_context()rather than trying to mutate the existing one. - Be intentional about what you pass in context. Context keys accumulate as they travel through the call stack. Passing unnecessary keys can lead to unexpected behavior in methods that check for those keys.
- Use context to pass flags for conditional logic. A common pattern is to pass a boolean flag like
from_wizard: Truein context, then check for it in a compute or onchange method to apply different behavior. This avoids polluting model fields with workflow state. - Document custom context keys in your module. Context keys are invisible unless you know to look for them. Add a comment or docstring explaining any custom context keys your module reads or sets. This pays off when you or a colleague returns to the code later.
Common Pitfalls
Context-related bugs can be tricky to diagnose because the context is invisible in the UI. These are the mistakes that come up most often in real projects.
Treating default_* as Mandatory Values
A default value set via context is only applied when a record is created through a form. If you create records programmatically via the ORM without passing the relevant context, the default will not be applied. Developers sometimes expect context defaults to behave like Python-level default parameters on fields. They do not. Always pass the context explicitly when creating records in code if those defaults matter.
Mutating the Context Dictionary Directly
The context dictionary is shared across the call stack. If you modify self.env.context directly, you can affect other code running in the same transaction in unexpected ways. The correct pattern is always self.with_context(new_key=value), which creates a new environment with a copy of the context plus your changes.
Passing Too Much in Context
Every key you add to context travels through the entire call chain. Some Odoo methods check for specific context keys and change their behavior accordingly. Passing unexpected keys can trigger those branches accidentally. Keep context lean and specific to what the immediate operation needs.
Forgetting active_test When Searching Archived Records
By default, Odoo's search() and search_read() methods filter out archived records (where active = False). If your code needs to work with archived records, you must explicitly pass active_test: False in the context. Forgetting this is a very common bug in inventory and product management customizations.
Context Conflicts Between Studio and Custom Code
If Odoo Studio has set context on a field in a view, and you later add a technical view extension targeting the same field, both contexts may conflict or one may override the other depending on the XML merge order. Always inspect existing context on a field before adding your own via a view inheritance. This is a particularly common issue when mixing odoo studio fields with module-based customizations.
Conclusion
Context is one of those mechanisms in Odoo that quietly does a lot of work. Once you understand how it flows through field definitions, view attributes, and the ORM environment, you gain a much finer level of control over how your data model behaves.
The key takeaways are straightforward. Use default_* keys to guide users toward correct data without forcing them. Put dynamic context in views rather than field definitions. Always use with_context() instead of modifying the context in place. And keep your context lean so it does not interfere with other parts of the system unexpectedly.
Whether you are working through an odoo field tutorial, building a custom module, or troubleshooting a field that is behaving strangely, understanding context will always be part of the answer.
At Dasolo, we help companies implement, customize, and optimize Odoo to fit their real business workflows. If you are working on a customization where context is involved and you are not sure you have it right, or if you just want to talk through your Odoo implementation, we are happy to help.
Reach out to our team via the contact page and let us know what you are building. We work with businesses of all sizes to get Odoo working the way it should.