package_m2o

Packages in Odoo Inventory can nest: a box goes on a pallet, the pallet into a container. A package's plain name, PACK0000123, tells a warehouse worker very little about where it sits in that hierarchy. This widget exists to show the right amount of that hierarchy at the right moment.

Structurally it is the standard many2one component wrapped with package awareness, wired on the source and destination package columns of detailed operations and batch transfer lines. The wrapping does three things: it forwards display flags to the server so the package's display name expands into its chain, it shortens names again once a transfer is done, and it fixes the awkward moment where a newly created package shows as Unnamed because its name comes from a sequence the client has not seen yet.

The widget encodes a warehouse truth: how much package context a person needs depends on what they are doing. While picking, the full chain, which pallet, which box, prevents wrong grabs at the shelf. Once the transfer is done, the chain is history and the short name keeps lists readable. Odoo made that a display rule so each screen does not have to relitigate it, and custom warehouse views should inherit the same thinking instead of reinventing package name formatting.

The second business relevant behavior is creation flow. Warehouse packages are typically named by sequence, and operators create them on the fly mid transfer. The widget's create dialog saves and reloads immediately so the operator sees PACK0000124, not a blank, which sounds cosmetic until you watch someone try to tell two Unnamed packages apart on a busy dock. Small UI guarantees like this are why we keep custom inventory screens on core widgets wherever possible.

How core wires the destination package column

<field name="result_package_id"
       widget="package_m2o"
       context="{'show_dest_package': True}"/>

Source package with the full hierarchy shown

<field name="package_id"
       widget="package_m2o"
       context="{'show_src_package': True}"/>

Locking down package creation on a custom view

<field name="package_id"
       widget="package_m2o"
       options="{'no_create': True, 'no_open': True}"/>

All the many2one lockdown patterns apply unchanged, because the widget inherits the full option set.

The display name round trip. The widget merges its two display flags and an is_done boolean, true when the parent record's state is done or cancel, into the field's context. Server side, stock.quant.package computes display_name from exactly those keys: done wins and returns the plain name, otherwise the destination or source complete name is returned when its flag is set. Client side there is a second guard: when the record is done and the value still contains a chain, the widget splits on the separator and keeps the last segment. Belt and suspenders, one server side, one client side.

The create dialog override. The autocomplete's create and edit path swaps in a dialog whose save handler saves with an immediate reload, then pushes the reloaded name back into the field. Package names come from sequences assigned at save time, which is why without the reload the UI shows Unnamed until the whole transfer is saved.

Undocumented inherited knobs. Because the base many2one extractProps is reused verbatim, two options absent from the declared list still work: can_scan_barcode, which core's barcode flows use, and create_name_field, which redirects what the typed text becomes on quick create. Both ride along into any view using this widget.

Odoo 20 is expected at Odoo Experience in Brussels, 24 to 26 September 2026, and these observations come from the public development branch, which remains changeable until feature freeze. We re-verify the page against the shipped release.

No behavior changes are visible for this widget. The master diff is a mechanical refactor: props declarations migrate to the new schema system, the dialog subclass moves inline, and the many2one props are re-declared in the new style with an explicit note that the base field still uses the old declaration. Context flags, done state collapsing, the create and reload flow and the inherited option set all survive unchanged.

One thing to watch is indirect: this widget inherits whatever the many2one family does in 20, so option level changes to the base field would flow through. Nothing of that kind is visible in the current branch state.