pick_from

The pick_from widget sits on the quant_id field of stock move lines in the detailed operations table. A quant is one pile of stock: a product in a location, possibly with a lot and a package. Picking a quant answers the warehouse question of where exactly to take the goods from, and the surrounding view then copies the quant's location, lot and package into the line.

Its trick is the empty state. A move line created by reservation carries location, lot and package fields without a quant reference, so a plain many2one would render blank. pick_from instead builds a display name on the fly from the line's own data, location, then lot or typed lot name, then package, joined with hyphen separators, and shows it as a value with id 0. The column therefore always reads like a pick instruction even when nothing was picked manually.

For warehouse teams the column is the pick list inside the transfer: FIFO or FEFO reservation fills it automatically, and workers only touch it when overriding, for example taking from a closer bin or an earlier expiring lot. The domain in the core view keeps honest choices only: quants of the same product, under the operation's source location.

The done state behavior is a nice audit touch: once the transfer is done or canceled, the package segment drops its full location path and shows just the package name, keeping history readable without the long internal paths.

<!-- Core usage on detailed operations (stock module, abbreviated) -->
<field name="quant_id" widget="pick_from"
       domain="[('product_id', '=', product_id), ('location_id', 'child_of', parent.location_id)]"
       context="{'show_src_package': 1, 'default_product_id': product_id}"
       options="{'no_create': True, 'no_open': True}"/>

The show_src_package context key is consumed server side by stock.quant.package display name computation, switching which package path the quant search results show. The widget itself only passes context through.

Reading _quant_display_name() closely pays off. It pushes the location display name, then the lot display name or the free typed lot_name, then the package name, shortened to the last segment after the transfer is done or canceled, and then data.owner. That last part is a bug in waiting: the field on move lines is owner_id, which is exactly what the widget declares in its field dependencies, but the code reads data.owner, which never exists, so the consignment owner silently never appears in the synthetic name. The location_dest_id dependency is likewise fetched and never used. Both dependencies survive on the development branch, so this is not going away in Odoo 20.

Version history: the widget appeared in Odoo 17 as a subclass overriding the many2one value getters with tuple values. Odoo 19 rewrote it as a standalone component composing the new Many2One, added the state dependency and the done state package shortening. The 17 and 18 files are identical.

Odoo 20 is expected at Odoo Experience in Brussels, 24 to 26 September 2026. The changes below are read from the public development branch and are not final until release.

No behavioral changes so far: the file is migrated to the new props system, and the display name builder, the dead owner read included, is untouched. The inherited many2one option set follows whatever the base widget does in 20. We re-verify after the release.