move_product_label_field

A stock move carries a product and, separately, a description used on the delivery paperwork. Often that description is just the product's name, because nobody changed it. Sometimes it is genuinely different: a customer reference, a packing instruction, a variant note.

This widget renders both in one cell, the product on top and the description beneath it, and applies one rule: if the description matches the product's name, it is treated as empty and nothing is shown. That keeps the list clean in the common case and informative in the rare one.

It also decides when the description can be edited. Being on a read-only field is not enough: the transfer itself has to be done or canceled. On a locked but not finished transfer the description remains editable, which is the behavior warehouse staff expect when they are correcting paperwork.

Delivery descriptions are one of those fields that is either invisible or important, with nothing in between. Printing the product name twice on every line makes an operations list harder to scan and a delivery note look sloppy, and hiding the description entirely loses the instruction someone deliberately wrote.

The rule this widget applies, show it only when it differs, is the right compromise and worth copying anywhere you have a description that defaults to a name. It costs nothing and removes visual noise from the screen people work in all day.

The core usage

<field name="product_id"
       widget="move_product_label_field"
       context="{'default_is_storable': True}"
       required="1" force_save="1"/>

Inside the operations list on a transfer. The description column itself is not declared; the widget renders it under the product.

Restricting the product dropdown

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

Inherited from the relation field, since the widget is built from the shared description builder.

The field it reads underneath

# on the move, read by literal name
description_picking
# blanked for display when equal to the product name

Not declared as a dependency, so the move must carry it.

Three small overrides make up the widget.

The label getter reads the description field, compares it with the product's display name, and returns an empty string when they match, trimming otherwise. That comparison is exact, so a description differing only in trailing whitespace is still shown, and one differing in case is shown too.

The read-only getter is the interesting one. It requires both that the field itself is read-only and that the parent record's state is done or canceled. Reading the parent through the evaluation context is what ties the widget to a form context; in a standalone list there is no parent, and the lookup would fail rather than degrade.

The visibility toggle for the label follows from those two: it is offered when the description is editable, the column is showing both product and label, and there is no label yet. In other words, the affordance to add a description appears exactly when adding one is possible and useful.

The last override neutralizes the parent's label parsing, keeping whatever the user typed verbatim. On sales and purchase lines the parent widget interprets the typed value; here the delivery description is taken literally.

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.

No behavior change. The label rule, the read-only condition and the literal parsing are identical on the development branch. The differences are internal, following the wider migration of the shared product label component it extends.