boolean_radio

Some yes/no questions deserve full sentences. The accrual plan form asks whether accrual is based on worked time, and the honest answers are Yes, consider the worked hours, excluding any time off taken during that period and No, always consider the entire accrual period. A checkbox cannot carry that; two radio buttons with sentence-length labels can. That is boolean_radio.

Mechanically it subclasses the standard radio field and overrides the item list for booleans: two entries, true and false, both with empty labels. The labels arrive in a second step. The widget's two options name DOM element ids, and on mount it copies each element's innerText onto the matching radio label. Core supplies those elements as <template id="is_based_on_worked_time_yes">...</template> blocks sitting right next to the field in the form, which keeps the sentences inside the view where Odoo's translation machinery picks them up.

Selection updates write the real boolean: the override converts the clicked string back to true/false and updates the record. The base class's change handler has no boolean branch, so the inherited call after it is a harmless no-op.

Configuration mistakes in HR are expensive: an accrual plan counting calendar days when the policy says worked days quietly misallocates leave for every employee on it. The difference between that and a correct setup is often nothing more than whether the form explained the choice. This widget exists to put the explanation inside the control, so the person configuring reads the consequence at the moment of choosing.

Use the same pattern on any consequential boolean in your own modules: approval required versus auto-approved, retroactive versus from-now-on, per-company versus global. The cost is a few lines of view XML; the payoff is one less paragraph in your onboarding doc and one less category of misconfiguration ticket.

The core pattern, from the accrual plan form

<field name="is_based_on_worked_time" widget="boolean_radio"
       options="{'yes_label_element_id': 'worked_yes', 'no_label_element_id': 'worked_no'}"/>
<template id="worked_yes">Yes, consider the worked hours, excluding time off taken in the period.</template>
<template id="worked_no">No, always consider the entire accrual period.</template>

The <template> elements render nothing themselves; they exist purely as text containers the widget reads by id.

Readonly gating still works

<field name="expected_hours_from_contract" widget="boolean_radio"
       readonly="base_off != 'quantity'"
       options="{'yes_label_element_id': 'ehc_yes', 'no_label_element_id': 'ehc_no'}"/>

The hr_attendance overtime rule form does exactly this: extractProps forwards the dynamic readonly, so conditional editability behaves like any field.

Three source-level details define this widget's limits in 19. First, the label transplant targets the radios through a document-wide query: document.querySelectorAll("[data-value='true']")[0]. The first boolean radio on the page wins, so two boolean_radio fields visible at once would write both label pairs onto the first widget's radios. Core never puts two on one screen; treat that as a constraint, not a coincidence.

Second, extractProps rebuilds the prop set from scratch and forwards only readonly plus the two ids. The base radio's horizontal option and its label and domain props are silently discarded, which is why the two radios always stack vertically no matter what the view asks. Third, a small fossil: the value getter's non-boolean branch returns the item list instead of a value, a copy-paste slip that is unreachable because the widget declares boolean as its only supported type, but a good reminder that this is a purpose-built component, not a general radio.

The template file ships one more oddity: a QWeb template named hr_holidays.BooleanRadio that replaces the boolean checkbox with a YES/NO select. No component references it, the class inherits the plain radio template instead, so it is dead markup in 19, and the development branch deletes the file.

Odoo 20 is expected at Odoo Experience in Brussels, 24 to 26 September 2026. We diffed this widget on the public development branch at the time of writing; the branch is unstable and can still change.

The rework is substantial. A third option appears, first_element, deciding which value renders first, and the default order flips: without it, No comes before Yes, the opposite of 19. The label transplant switches from the global attribute selector to per-instance element ids, fixing the two-widgets-per-page collision. The descriptor starts spreading the base radio's options and extractProps, so horizontal becomes functional. The dead hr_holidays.BooleanRadio template file is deleted, and the source quirk of typing first_element as Boolean with a capital B ships as written. We re-verify after release.