stock_move_one2many

A transfer's operations list is where a warehouse says what is actually moving. Normally that is line by line: a product, a quantity, a destination. Sometimes it is not: an entire package has to move as a unit, and typing out its contents defeats the point of having packaged it.

This widget is the operations list with that case built in. It renders the moves with the same product name and description behavior sales and purchase lines use, and adds an action that opens a list of packages and, on selection, asks the server to add every line inside them.

The action has a precondition that is easy to miss. Packages are filtered by the transfer's source location, and the server needs a real picking to attach the lines to, so the widget saves the picking before opening the dialog. If that save fails, the dialog does not open at all.

Moving stock by package rather than by line is the difference between a two minute transfer and a twenty minute one in any warehouse that packs goods. It also reduces transcription errors, because nobody retypes contents that the system already knows.

The conditions on when the action appears are worth knowing, because they are the usual reason someone reports the button missing. Package tracking has to be switched on, the transfer must still be editable, and it cannot be an incoming transfer: goods arriving are not yet in a package the system knows about.

The forced save is the other thing to brief people on. Adding packages commits the transfer, so a draft you were still assembling becomes a saved record at that moment. On a picking that is the right trade, but it surprises people who treat the form as scratch space.

The core usage, trimmed

<field name="move_ids_without_package"
       widget="stock_move_one2many">
  <list editable="bottom">
    <field name="product_id" widget="move_product_label_field"/>
    <field name="package_ids" widget="package_m2m" readonly="1"/>
  </list>
</field>

The widget is designed alongside its companion cell widgets, which is why they appear together in the core view.

The context it reads

# from the embedded list's context
picking_state       # hides the action on done or canceled
picking_type_code   # hides the action on incoming transfers

Both are read from the list's context rather than from the record, so a custom subview has to supply them.

What the action calls

# server side, with the picking id and the chosen package ids
stock.picking.action_add_entire_packs(...)
# then a client-side soft reload

The lines are created by the server, not assembled in the browser, which is why a reload follows.

The sequence behind the package action is worth following, because every step exists for a reason.

First it saves. The comment in the source says the picking may not exist yet, and that an outdated location would produce the wrong package list. So the save both creates the record and refreshes the location the filter is built from. If the save is rejected, the method returns and no dialog opens.

Then it builds a domain restricted to packages under the source location, and opens a multi-select dialog on the package model with creation disabled and a named simplified list view. Choosing nothing closes without effect.

On selection it calls a server method with the picking id and the chosen package ids, and if the server reports success it triggers a soft reload of the whole action rather than inserting rows locally. That is heavier than a local update but correct: adding a package can change quantities, reservations and availability across the transfer, none of which the browser could recompute.

The availability of the button is computed from three things: the package tracking group, resolved once when the component starts, and two context keys naming the transfer's state and operation type. Because the group check is asynchronous and happens on startup, the button can appear a moment after the list renders.

The Odoo 19 rewrite is substantial. The earlier version extended an auto-sizing column renderer and injected an extra details column into the list; the current one uses the plain list renderer and instead shares the product name and description behavior with sales and purchase lines through a patched mixin. Anything customizing the old column arrangement has to be redone.

Odoo 20 is expected at Odoo Experience in Brussels, 24 to 26 September 2026. The development branch is unstable and this may still change; we re-verify the page after release.

One rename, no behavior change. The template constant naming the rows template is renamed on the development branch. The package action, its preconditions, the server call and the soft reload are identical.