This technical addon allows developers to specify a field domain in a view using the value of another field in that view, rather than as a static XML attribute.
auto_awesome What this module does
AI-generated from the code · Odoo 16.0Lets a view use the value of another field on the same screen as the filter (domain) for a field, instead of a fixed filter written in the view. It is a technical building block for developers.
This is a technical module with no menus, screens or database models of its own. It changes how Odoo views can be built: normally the list of allowed values shown for a field (its "domain", i.e. the filter applied to the records offered) is fixed when the view is written. With this module, that filter can instead come from the current value of another field in the same view.
What this means in practice:
- A developer can point a field's filter at another field, so the choices offered update according to what the user has already entered or selected on the form.
- The module only adds front-end code loaded in the Odoo backend interface; it declares no new models, no menus, no reports and no scheduled actions.
- It depends only on the standard
webmodule, so it does not modify any business area such as sales, stock or accounting by itself.
Because the module contains no server-side models and no data files, there are no business rules, checks, default values or emails added. Its effect is only visible when a developer uses it in a custom view; end users simply see field choices that adapt to the rest of the form. The manifest also registers test files for the interface test suite, which confirms the feature is verified in the backend client.
Depends on
Text generated by AI (DeepSeek) from reading the Odoo 16.0 code on GitHub; it may contain mistakes, so check the code before deciding. View the code on GitHub
Availability by version
Reviewed: 2026-11-03Confirmation status: 5 confirmed, 4 with no information of 9 versions.
Sources · Odoo 12.0
Confirmed on 2026-11-03 in branch 12.0 of OCA/web.
terminal Installation and usage
OCA documentation · Odoo 16.0Usage
Source · Odoo 16.0When you define a view you can specify on the relational fields a domain attribute. This attribute is evaluated as filter to apply when displaying existing records for selection.
<field name="product_id" domain="[('type','=','product')]"/>The value provided for the domain attribute must be a string representing a valid Odoo domain. This string is evaluated on the client side in a restricted context where we can reference as right operand the values of fields present into the form and a limited set of functions.
In this context it's hard to build complex domain and we are facing to some limitations as:
- The syntax to include in your domain a criteria involving values from a x2many field is complex.
- The right side of domain in case of x2many can involve huge amount of ids (performance problem).
- Domains computed by an onchange on an other field are not recomputed when you modify the form and don't modify the field triggering the onchange.
- It's not possible to extend an existing domain. You must completely redefine the domain in your specialized addon
- etc...
In order to mitigate these limitations this new addon allows you to use the value of a field as domain of an other field in the xml definition of your view.
<field name="product_id_domain" invisible="1"/>
<field name="product_id" domain="product_id_domain"/>The field used as domain must provide the domain as a JSON encoded string.
product_id_domain = fields.Char(
compute="_compute_product_id_domain",
readonly=True,
store=False,
)
@api.depends('name')
def _compute_product_id_domain(self):
for rec in self:
rec.product_id_domain = json.dumps(
[('type', '=', 'product'), ('name', 'like', rec.name)]
)You do not actually need this module to craft a dynamic domain. Odoo comes with its own py.js web library to parse expressions such as domains. py.js supports more complex expressions than just static lists.
Here is an example of a conditional domain based on the value of another field:
For OCA modules, this method is preferred over adding this module as an additional dependency.
No verified information in OCA: Installation, Configuration.
Installation instructions, the distribution package, dependencies and configuration steps are not shown because they have not yet been verified in the module documentation for any version.
Data imported from GitHub: this sheet reflects the latest catalog review, not a live lookup. Always check the module documentation and staging before installing in production.