OD316 unknown-modifier-name¶
A view modifier names a field its model does not have.
| Category | Severity | Series | Needs the index |
|---|---|---|---|
| Correctness | Error | 17.0 and later | yes |
What it reports¶
A name in an invisible, readonly, required or column_invisible expression that is no field
of the model at the element's position, the view's or the comodel of the subview that encloses it.
parent.x reads the model one subview up, and parent.x.y is reported whatever x is, since Odoo
refuses a composed field there. Lowercase true and false inside an expression are names like any
other. So are those two when whitespace surrounds them in <attribute> text, and when an add joins
them to a value the element holds, since only a value that is exactly a constant skips the check.
Write True or False, which are no names. OD315 says when an add joins a value.
The names Odoo's view validation ignores, such as context, uid or today, and id are fine. So are active_id, active_ids and active_model before saas~17.1. Only the first name of
a path counts: state.x reads state.
Why it matters¶
Odoo checks these names when it validates the view, so a misspelled one stops the install or the upgrade of the module. A demo file differs: see load failures.
The rule stays silent when it cannot see every class or tell the model: a module whose dependencies
include one that is not indexed, a module that builds model names at runtime, a model that is
unknown or outside depends, a class with a plain Python base or an _inherit no indexed module
defines, a class in a file that does not parse, which counts as one the scan cannot
read, and an element an xpath places in a position that only the parent view can tell. A field
that only a module outside depends adds is not reported, nor is parent.x outside any subview,
which Odoo ignores. A field an ir.model.fields record adds counts, as OD304 describes.
An element of an extension may land in a subview of the parent view, so it is also left alone when a subview of the inheritance tree has the name, when a subview's model is unknown or the scan does not see every class of it, and when the tree is not fully indexed. One such subview silences the rule for every extension of that tree.
Only a file Odoo loads gives the tree a subview, as OD310 spells out (18.0
odoo/modules/loading.py:39-48), so a subview that only an extension in any other file adds
silences nothing: list that extension under data. An extension with a parent at any level found
only in such a file is left alone: its tree is unknown.
A subview that an extension puts directly inside a field of the parent view reads that field's
comodel, as Odoo validates it. A name of the view's model alone is reported against the comodel, and
parent.x reads the view's model. A subview under another position, or wrapped in another element,
stays on the model around it. A spec locates the first field of that name anywhere in the parent
view, so nothing is reported in such a subview when a subview of the tree is on a model that also
has the located field: the comodel may be another one.
Syntax is OD315's.
Example¶
sale.order has no stat, so the module fails to install.