stock_action_field

A number in a list often answers one question and raises another. Seeing that a product has 42 on hand immediately prompts where, and the usual answer is to leave the list, open the product, and find the stock view from there.

This widget shortens that. It renders the value exactly as a decimal or currency field would, and makes it clickable: the click opens a named action, with additional context taken from the field's own context attribute and evaluated against the record.

Which renderer it uses is decided from the field's type rather than configured, so the same widget name serves a quantity column and an amount column. A per-record expression can disable the click where following it would make no sense.

Clickable figures are one of the cheapest usability improvements available in an ERP, and inventory is where they pay off most, because almost every number invites a follow-up question. The alternative, teaching people a navigation path, costs training and gets forgotten.

The pattern is worth reusing beyond stock. Any list where a computed total should lead somewhere, a receivable balance, an open task count, a pending approval figure, can use the same idea. What makes it work is that the destination is an action name plus context, so the target screen opens already filtered to the record you clicked from.

The one caution is that clicking navigates away. On a form with unsaved changes that is disruptive, which is presumably why the widget is used on a list in core rather than on a form.

The core usage, trimmed

<field name="qty_available"
       widget="stock_action_field"
       sum="Total On Hand"
       options="{'action_name': 'stock.dashboard_open_quants'}"
       context="{'search_default_product_id': id}"/>

The action opens the stock view, and the context expression pre-filters it to the clicked product.

Disabling the click per record

<field name="qty_available"
       widget="stock_action_field"
       options="{'action_name': 'stock.dashboard_open_quants',
                  'disabled': "is_storable == False"}"/>

The expression is evaluated against the record, so consumable products can be shown without a link.

On a currency column

<field name="stock_value"
       widget="stock_action_field"
       options="{'action_name': 'stock_account.action_valuation'}"/>

The renderer follows the field's type, so a currency field is formatted with its currency and no extra option is needed.

The component is a small wrapper rather than a subclass. It holds both the decimal and the currency components, reads the field's type when it starts, and renders whichever matches, forwarding every prop except its own three.

The extractor is where the type branching happens. It always builds the three action props: the action name from the options, the disabled expression from the options, and the context taken from the field's context attribute. It then merges in the decimal or currency extractor's own props depending on the field type. A field of any other type gets only the action props, which means the value renders without the formatting that widget would normally apply.

The click handler stops the event, evaluates the context expression against the record, and asks the action service to open the named action with that context merged into the record's own. Nothing is written and nothing is saved first, so a form with pending edits will navigate away with them pending.

Two details are worth flagging for anyone extending this. The disabled expression and the context are read in the extractor but never declared as supported options, so no tooling will suggest them. And there is a commented-out line in the source showing an earlier approach that called a method on the record instead of opening an action, which is a useful hint about where the design started.

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.

Behavior is unchanged. The action name option, the per-record disabling, the context evaluation and the type-driven renderer choice are all identical on the development branch. The differences follow the wider component migration and affect patches rather than views.