base_automation_actions_one2many

An automation rule can perform several actions: update a field, send an email, add followers, create an activity. Showing them as an embedded list would take a block of vertical space for what is usually two or three short labels, on a screen where the trigger and its conditions matter more.

This widget lays them out horizontally instead, as a compact strip of action labels on one line. The problem with one line is that it has a width, and a rule with six actions will not fit. So the widget measures.

After rendering, it reads the real width of the container and of every action in it, works out where the overflow starts, hides everything from that point on, and shows a counter saying how many are hidden. Resize the window and it does the whole thing again.

This is a density decision rather than a feature. Automation rules are scanned more often than they are edited, and what a reader wants from the actions column is a rough sense of what the rule does, not the full definition. A strip that says Update Stage, Send Email and 2 more answers that in a glance and takes one line.

The general lesson for custom interfaces is that overflow is a layout problem best solved by measuring, not by guessing a character count. Truncating at a fixed number of items breaks on a wide screen and on a narrow one in opposite directions; measuring adapts to both, and to translations, which are the usual reason a guessed limit stops working.

The core usage

<field name="action_server_ids"
       widget="base_automation_actions_one2many"
       class="align-self-center w-100 me-md-3"/>

The full width class matters: the widget measures its container, so a container without a defined width gives it nothing to work against.

The fields it injects

# added to every action record automatically
name     # shown as the label
state    # the action type

Both are declared as related fields on the registration, so the view does not have to load them.

The plain list instead

<field name="action_server_ids">
  <list> <field name="name"/> </list>
</field>

Vertical, complete, and taller. The right choice on a form where the actions are the main subject.

The measuring routine is the whole widget, and it is careful in two ways worth copying.

First, it removes any hiding classes before measuring. An element that is already hidden has no width, so measuring without resetting would compound the previous pass and progressively hide everything. Clearing first means each pass starts from the true widths.

Second, it uses the unrounded bounding rectangle rather than the integer offset width, with a comment saying so. Summing rounded widths across half a dozen elements accumulates enough error to hide one item too many or too few, and on a strip of short labels that is visible.

The overflow point is found by walking the actions and accumulating width, starting from a reserved allowance for the counter. The first element that would push the total past the container width becomes the overflow point, and it and everything after it are hidden. The hidden count is then derived from that element's position in the list.

A re-render is triggered only when the hidden count actually changes, which keeps the resize handler from causing a render on every animation frame. The resize listener itself is throttled to animation frames for the same reason.

The Odoo 18 version carried a map from each action type to a human label, so the strip read Send email rather than the action's own name. Odoo 19 removed that map and shows the action's name field instead, which means a badly named action now shows its bad name rather than a generic type label.

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.

Same behavior, new helpers. The measurement, the reserved counter width, the throttled resize handling and the render-only-on-change rule are all identical. The component moves to the new rendering, listener and reference helpers, which affects code that patches it rather than views.