line_open_move_widget

Analytic lines carry a move_line_id pointing at the journal item they were generated from. With a plain many2one widget, the internal-link arrow next to that field opens the raw account.move.line form, a screen almost nobody wants, since a journal item out of context answers no business question.

line_open_move_widget keeps everything else about the many2one, the autocomplete, the domain handling, the option set, and swaps the arrow's destination. Its openRecordAction override calls the server method action_open_business_doc on the related record, which resolves the most meaningful representation: the customer invoice if the item belongs to one, the payment if it is a payment line, the journal entry otherwise.

Editing is untouched. Users can still search, pick or clear the journal item like any relation, and core wraps the field with no_create so analytic screens cannot spawn journal items by accident.

Analytic accounting is where controllers reconcile operational truth with the books, and the loop is always the same: this cost line looks off, show me the document behind it. This widget makes that loop one click long. From an analytic item you land directly on the vendor bill or payroll entry that produced it, with no detour through a journal-item form that lacks every piece of context.

The detail worth teaching your team: the arrow deliberately skips the record it technically points to. Users trained on standard many2one behavior sometimes report it as a bug, expecting the move line form. It is the opposite of a bug; the routing is the feature.

For custom analytic or costing models that also reference journal items, reusing this widget gives your screens the same drill-down for free. That, plus a no_create to keep data entry clean, is a pattern we apply in most analytic accounting setups we deliver.

How core uses it (analytic line form)

<field name="move_line_id"
       options="{'no_create': True}"
       widget="line_open_move_widget"/>

In the analytic items list, hidden by default

<field name="move_line_id"
       widget="line_open_move_widget"
       optional="hide"/>

Both usages relate to account.move.line, which matters: the override calls action_open_business_doc with resModel: "account.move.line" baked in and the related record's id. Reuse the widget only on fields whose comodel is account.move.line; on any other relation the id would be sent to the wrong model and the click would error or open something unrelated.

The override is three lines; the routing is server side. openRecordAction replaces the m2o's standard open with a doActionButton of type object calling action_open_business_doc, passing this.props.record.data[this.props.name].id, the id of the linked journal item. All if-this-then-invoice logic lives in the Python method, so widget behavior automatically tracks any server-side improvement to document resolution.

The 19 rewrite changed the shape, not the behavior. Through 16, 17 and 18 the widget was a Many2OneField subclass; 17 and 18 are byte-identical descriptor-style files. Odoo 19 rebuilt it on the composition API, a template rendering the shared Many2One component with computeM2OProps plus the one overridden callback, part of the framework-wide m2o decomposition. Anyone who patched the old class needs to re-target the new component, the classic post-migration JavaScript fix.

Value access drifted with the record API. 16 read props.value[0], 17 and 18 read record.data[name][0] off the id-name tuple, 19 reads record.data[name].id off the record-like value object. Any copy-pasted derivative widget carries the era of its source.

Odoo 20 is expected at Odoo Experience in Brussels, 24 to 26 September 2026. The notes below come from the public development branch, unstable until feature freeze, and this page is re-verified after release.

The widget's file shows no behavioral change: the class, the hardcoded account.move.line model, the registration and both core usages survive. The only diff is prop plumbing, useProps with the shared many2OneFieldProps replacing the static props declaration, the same modernization sweeping every m2o-family widget on the branch.

The practical migration note is inherited instead: base many2one behavior keeps evolving on master, and since this widget spreads the m2o descriptor, whatever lands there lands here. Include it in the widgets you smoke-test during an Odoo 20 migration, but expect it to just work.