radio_followed_by_element

Some configuration reads best as a sentence with a blank in it: "carry over on ( ) January 1st ( ) other: [date]". HTML forms fight this layout, because the date input belongs to the form's field grid while the radio options are rendered inside a single field widget. Odoo 19's answer in the Time Off app is this widget: a radio field that, after mounting, finds designated elements elsewhere in the view by id and appends each one directly after the radio option it belongs to.

Configuration is two options. links is a mapping from radio option values to DOM element ids, for example {'other': 'carryover_custom_date'}: the element with id carryover_custom_date is moved to sit after the option whose value is other. observe names the container (matched by the name attribute) that the widget watches with a MutationObserver, so when Odoo re-renders that area and recreates the elements in their original spots, the widget moves them back into place.

Everything about the radio itself, value handling, rendering of options, is inherited from the standard radio widget.

The payoff is forms non-specialists can read aloud. Odoo's accrual plan editor asks questions like when a milestone triggers or how carryover caps apply, and each answer may need a companion value: a date, a number of days. Rendering those companions inline after the option that activates them, instead of in a detached row below, is the difference between a policy screen an HR manager configures alone and one that needs a consultant on a call.

For customizers, this widget is interesting as a sanctioned pattern. "Put this input inside that widget's layout" is a request every Odoo integrator has heard, and the usual answers, template inheritance or CSS contortions, are brittle. Core now demonstrates the DOM-move approach with an observer to keep it stable across re-renders. It is still the most invasive trick in the fields registry, and the constraints are real: ids must be unique and present, and anything else that moves those nodes will fight the observer. Use it for sentence-style config screens, not as a general layout tool.

As core uses it for the carryover date

<field class="ms-1" name="carryover_date"
       widget="radio_followed_by_element"
       options="{'links': {'other': 'carryover_custom_date'}, 'observe': 'carryover'}"/>
<span id="carryover_custom_date">
    <!-- the inline date fields live here -->
</span>

The span with the matching id is authored anywhere convenient in the same view; the widget relocates it after the other option. The observed container is the element whose name attribute is carryover.

Several options with companions

<field name="milestone_date" widget="radio_followed_by_element"
       options="{'links': {'after': 'milestone_date_after', 'on': 'milestone_date_on'}, 'observe': 'milestone_date'}"/>

Each entry in links pairs one radio value with one element id, so different options can each get their own inline companion.

Reading moveElement closely tells you where this can bite.

Matching is by data-value attribute selector. The radio options render with data-value set to the selection value, and the widget queries [data-value=<key>] globally on the document, taking the first match. Two consequences: keys must be valid unquoted CSS attribute selector material, which numeric-looking or exotic values are not, and two instances of this widget with overlapping selection values on one page can grab each other's options.

The move is appendChild into the option's parent. Not a copy: the element genuinely leaves its authored position, with its Owl bindings intact, which is why the moved element can contain live fields. The guard skips the move when the element is already in place.

The observer's filter is broken and it does not matter. The MutationObserver callback builds a list of added node ids and calls .filter(...) on it, then treats the resulting array as a condition. An array is always truthy in JavaScript, so the widget re-runs the move on every childList mutation in the observed subtree, not just relevant ones. The intended optimization never fires; the observed effect, elements snapping back after each re-render, works anyway because the move is idempotent. The same code survives on master with cosmetic reformatting, so this stays true for Odoo 20 as of today.

The observed element is found by document.getElementsByName. Meaning the observe value must match a name attribute, the convention Odoo form groups and spans already follow, and it must exist at mount or the observer call throws.

Odoo 20 is expected at Odoo Experience in Brussels, 24 to 26 September 2026. These notes are read from the public development branch, which is unstable until feature freeze; we re-verify against the shipped release.

The file survives on master with formatting-only changes: the code is reindented and the props migrate to the new validation syntax, with links and observe still required. The registration, both options, the global data-value querying, and the always-truthy observer filter are all unchanged. No behavioral difference is expected for Odoo 20 based on the branch today.