checkbox

This page documents a widget that does not exist, because Odoo's own views use it anyway. In Odoo 19, the Time Off leave type form sets widget="checkbox" on two boolean fields, requires_allocation and employee_requests. Search the entire 19.0 source for a registration of that name and you find nothing: the boolean field widget is registered as boolean, the web CheckBox is a UI primitive outside the fields registry, and no module adds a field widget called checkbox.

What saves the view is the fallback in getFieldFromRegistry. When a requested widget name is missing, the engine logs Missing widget: checkbox for field of type boolean to the console and resolves the field by its type instead. The default widget for a boolean is the standard checkbox, so the form renders precisely what the view author intended, and end users never notice.

The two core usages are themselves 19-new: in Odoo 18 requires_allocation was still a yes/no selection, and the boolean conversion arrived together with the redundant widget attribute.

Why give a non-widget a page? Because that console line is one of the most searched Odoo warnings, and the standard advice, install a missing module, is wrong here. The warning is harmless when the fallback matches intent, as it does for booleans, and knowing that saves an afternoon of dependency archaeology. OCA's quality tooling even whitelists known-harmless cases of exactly this warning.

There is also a review lesson in it. Customizations copied from core views inherit the phantom name, and every copy multiplies the console noise that then obscures real warnings. A five-minute sweep of your custom views for unregistered widget names, checkbox is the most common offender, keeps the console meaningful for the warnings that do matter.

What core writes (and you should not copy)

<field name="requires_allocation" widget="checkbox"/>
<field name="employee_requests" widget="checkbox"
       invisible="not requires_allocation"/>

Verbatim from the 19.0 leave type form. It works through the fallback and logs one warning per field per render.

The clean equivalents

<!-- rely on the type default -->
<field name="requires_allocation"/>
<!-- or name the real widget -->
<field name="requires_allocation" widget="boolean"/>

Identical rendering, no warning.

The resolution order in getFieldFromRegistry is worth memorizing, because it explains every Missing widget situation, not just this one. Given a widget name, the engine tries the view-prefixed key first, list.checkbox in a list view, then the bare name. Found entries are returned even when their declared types do not include the field's type, that mismatch only logs its own warning. If the name is missing entirely, the engine logs the Missing widget line and repeats the same lookup with the field's type as the key, boolean here, which resolves the standard checkbox. Only if even the type has no entry does a bare default component render the raw value.

Two practical corollaries. First, the fallback means a typo in a widget name never breaks a view, it silently degrades to the type default, so a missing custom widget after an upgrade shows up as changed behavior plus a console line, not a traceback. Second, the warning fires on every render of the view, which is why one phantom name can flood a console during QA sessions.

Odoo 20 is expected at Odoo Experience in Brussels, 24 to 26 September 2026. We checked the development branch at the time of writing, unstable as it is, on exactly this question.

Both core usages disappear: the leave type views are restructured and no widget="checkbox" remains in hr_holidays. Separately, a widget named boolean_checkbox appears in web, a one-getter subclass of the boolean field that opts out of the new mobile toggle rendering by forcing displayAsToggle to false. Note the name: it is boolean_checkbox, not checkbox, so the phantom name stays unregistered. We re-verify after release.