package_m2m

A stock move can be split across several packages, and some of its quantity may not be packed at all. Showing that as a table would take a block of space on every line; showing only the package names loses the unpacked part.

This widget renders the packages as tags and then adds one more when needed. If the move has lines without a package, a synthetic No Package tag joins the real ones, so a glance at the column tells you both what is packed and that something is not.

It is meant to be read, not edited. The core view marks the field read-only, and the code backs that up: the widget's own initialization replaces the parent's rather than extending it, so none of the tags widget's editing behavior is set up.

Partially packed moves are the case that causes disputes at the receiving end, because the paperwork says one thing and the pallet says another. Surfacing the unpacked remainder in the same column as the packages puts that on the screen of the person who can still fix it.

The read-only intent is worth respecting in customizations. Making the field editable in an inherited view will render an input that has none of the machinery behind it, because the widget never initialized it. If packages need editing, that belongs on the detailed operations rather than on this summary column.

The core usage

<field name="package_ids" widget="package_m2m"
       optional="show" readonly="1"
       groups="stock.group_tracking_lot" width="200px"/>

Read-only and group-gated. Both are part of the intended usage rather than incidental.

The companion field it reads

# on the move, read by literal name at setup
has_lines_without_result_package
# true adds the synthetic No Package tag

Not declared as a dependency, so the move must carry it for the extra tag to appear.

The plain tags widget

<field name="package_ids" widget="many2many_tags"/>

Editable and fully wired, but with no No Package tag and printing display names instead of package names.

Three details define this widget, and two of them are unusual enough to be worth stating plainly.

First, its initialization does not chain to the parent. It sets one property and stops, which means every hook the tags widget would normally install, including the ones that handle adding and removing tags, is never created. That is not an oversight to work around; it is why the field is declared read-only in the view. Treat the widget as a display component.

Second, the synthetic tag is built by copying the properties of the last real package in the list and then replacing its identifier and text. That is a pragmatic way to get a tag with the right shape, and it has a visible consequence: the No Package tag inherits whatever color and options that unrelated package had. On a move with no packages at all, there is no record to copy from.

Third, tags print the package's name field rather than its display name, and the descriptor injects that field into the related data so the view does not have to request it. That keeps the column narrow, because package display names carry additional context that would not fit.

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.

Reworked alongside the tags components. The development branch changes this widget as part of the wider rework of how tags are built, in the same wave that reshaped other tag widgets in core. The No Package concept and the read-only intent are unchanged; the internals are not.