open_move_widget

The Journal Items list is where accountants live during a close, and every line on it belongs to a journal entry. The open_move_widget makes the move_name column a navigation device: instead of a plain text cell it renders an anchor with the entry number, and clicking it executes the server action action_open_business_doc on that line.

That server method is the clever part. It does not open the raw account.move form blindly; it resolves the most useful representation of the document. A line that belongs to a customer invoice opens the invoice form, a payment line opens the payment, and a manual entry opens the journal entry itself. The widget contributes exactly one thing, the click; all routing intelligence lives server side.

The template is a single anchor: <a href="#" t-out="value || '/'">. When the field is empty the widget prints /, which mirrors the placeholder number Odoo gives entries before they are posted, so unposted lines still show something clickable.

The value is navigation speed during reconciliation and audit work. A controller scanning thousands of journal items does not want a three-click detour through the entry form to see the invoice behind a line. One click on the entry number lands on the business document, and the browser back button returns to the filtered list exactly as it was.

There is a subtle discipline benefit too. The Journal Items list is editable with multi-edit enabled, which is powerful and slightly dangerous. Because this widget renders a link instead of an input, the entry number itself cannot be mass-edited from the list, while neighboring columns can. The widget quietly protects the one column that must never be bulk-changed by accident.

If your team has custom operational lists that reference accounting entries, stock valuation layers, custom reconciliation screens, this widget is a free, proven way to give them the same one-click drill-down instead of building a custom button. Wiring it into custom list views is routine Odoo view customization work.

How core uses it (Journal Items list)

<list name="move_line_tree" create="false" edit="true" multi_edit="1">
    <field name="move_name" string="Journal Entry" widget="open_move_widget"/>
    <!-- other columns stay editable; this one becomes a link -->
</list>

Reusing it on a custom model

<field name="reference" widget="open_move_widget"/>

Since Odoo 17 the click runs action_open_business_doc on the view's own model with the current record's id. Your model therefore needs a method with that exact name returning an action; without it the click raises an RPC error. On account.move.line the method ships with core.

The widget never edits anything. The component renders only the anchor, so there is no input element in any state. In an editable list the cell simply does not enter edit mode for this column. If you need the number editable somewhere, that somewhere is the entry form, not the list.

The click handler stops the row click. The anchor uses t-on-click.prevent.stop, so clicking the number does not also trigger the list row's own open behavior. You get exactly one navigation, to the business document.

The Odoo 16 version was hardwired. In 16 the component called action_open_business_doc with resModel: "account.move.line" baked in, and a second legacy implementation shipped alongside it for the old view engine. Odoo 17 replaced the hardcoded model with this.props.record.resModel and dropped the legacy file, which is what made the widget reusable outside accounting. From 18 the file has not changed at all; 18, 19 and the current development branch are byte-identical apart from a removed module pragma.

Odoo 20 is expected at Odoo Experience in Brussels, 24 to 26 September 2026. We read the development branch directly rather than relying on release notes, with the usual caveat that the branch is unstable until feature freeze and this page gets re-verified against the shipped release.

For this widget the answer is short: nothing changes. The JavaScript is identical to Odoo 19, and the template's only edit is the framework-wide rewrite of expressions to the explicit this. prefix. Both core usages on the Journal Items and Payment Items lists are still in place. Custom views using the widget should migrate without any attention.