boolean

Every boolean field in Odoo renders through this widget unless a view says otherwise. It draws a standard checkbox, checked or unchecked, wired to the field's true or false value. Clicking it in an editable view updates the record in memory; the change is written to the database only when the record is saved, which is the key behavioral difference from the self-saving toggle and favorite variants.

The component is deliberately tiny. In the Odoo 19 source it is about 40 lines: a checkbox component, an observer that mirrors the record value into local state, and an update call. Its registry entry declares supportedTypes: ["boolean"] and nothing else. When the field or the view is readonly, the checkbox renders disabled but stays visible.

One subtlety in the descriptor: isEmpty is hardcoded to false. Odoo hides empty fields in some rendering paths, and a false boolean would otherwise look "empty". This line is why an unchecked checkbox still occupies its place on the form instead of vanishing.

Checkboxes are the smallest decision in a form design, and still one of the easiest to get wrong. The default widget requires a save, which is right for data entry: a user reviewing a supplier form can tick Is a Vendor, keep editing, and discard everything if they change their mind. Nothing has hit the database.

The moment a checkbox is meant to be an action rather than a data value, the default is the wrong widget. Marking a task done, activating a product, starring a favorite: users expect one click to take effect immediately, without hunting for a save button. Odoo core follows exactly this split, using boolean_toggle and boolean_favorite for act-now fields and the plain checkbox for describe-and-save fields. Copying that convention in your own views keeps behavior predictable for users who already know Odoo.

The other business decision is list views. A column of editable checkboxes in a list is an invitation to bulk-edit, which is powerful for an operations team and dangerous on fields that drive automation. If ticking the box triggers a workflow, consider making it readonly in the list and editable only on the form, where the user sees the context.

Booleans are the simplest field to add without a developer. Odoo Studio is available on Enterprise plans.

1. Open the form you want to change and click Studio in the top menu.

2. From the Add a field panel, drag Checkbox onto the form. Studio creates a boolean field on the model.

3. Select the field and open Properties on the right to set the label, help tooltip, and default value.

4. To change how it renders, set Widget to Toggle for a self-saving switch or Favorite for a star. Leaving it on Checkbox keeps the widget described on this page.

Tip: set the default value in Studio rather than training users to tick the box on every new record. A boolean that should usually be true and defaults to false generates a surprising amount of bad data over a year.

Studio handles creation, defaults, and the widget swap. What it does not give you for a checkbox:

Immediate save. There is no Studio switch that makes the plain checkbox commit on click. That behavior belongs to the boolean_toggle and boolean_favorite widgets, so the fix is choosing a different widget, not an option.

Conditional visibility based on complex rules. Studio's conditional display covers simple cases; anything involving computed conditions or company-dependent logic needs view XML or a computed field.

Side effects. A checkbox that should trigger anything, an email, a stage change, a recomputation, needs an automation rule or server-side code. The widget itself only writes true or false.

The implicit default, no widget attribute needed

<field name="active"/>

Any boolean field renders as this checkbox automatically. This is how nearly all of Odoo's thousands of boolean fields use it.

Explicit spelling, used to override another default

<field name="is_published" widget="boolean"/>

The explicit form matters when a field would otherwise pick up a fancier widget, for example from a view inheriting a parent that set widget="boolean_toggle". Core does this in website and mrp to force the plain checkbox back.

Readonly display in a list

<field name="is_vendor" readonly="1"/>

The checkbox renders disabled but visible. Users can see the state and cannot bulk-flip it from the list.

Two source-level details are worth knowing.

The value flows through an observer, not straight from the record. The component copies record.data[name] into local state via useRecordObserver and renders from that copy. In practice this means the checkbox updates instantly when an onchange elsewhere on the form flips the boolean server-side, a behavior custom widgets sometimes lose when they read the record only on setup.

isEmpty: () => false is doing quiet layout work. Odoo's form rendering can suppress empty fields, and kanban card templates frequently skip them. Because this widget reports itself as never empty, boolean fields render in both states. If you build a custom boolean widget and forget this line, unchecked fields start disappearing from kanban cards, which looks exactly like a data bug and is not.

There is also a small trap in what the widget does not do: it never saves. In an editable list view, ticking a checkbox puts the row in edit mode and the change is only committed when the row loses focus or the list saves. Users coming from the toggle widget sometimes report the checkbox as "not working" when in fact their edit was discarded by a navigation away from the unsaved row.

Odoo 20 is expected at Odoo Experience in Brussels, 24 to 26 September 2026. Odoo develops in the open, so the notes below are read directly from the public development branch. That branch is unstable and can change until feature freeze; we re-verify this page against the shipped release.

The interesting change is visual: the master-branch template renders the checkbox as a switch-style toggle on small screens. The component gains a displayAsToggle getter returning ui.isSmall, and the template applies the o_boolean_toggle form-switch classes when it is true. Desktop rendering is unchanged, but on phones every plain boolean in your database will look like a toggle while still requiring a save like a checkbox. If your training material screenshots mobile forms, expect them to date.

The registry entry itself is unchanged: still no options, still supportedTypes: ["boolean"], still never empty. The rest of the diff is Odoo's framework-wide migration to the new useProps validation system, with no behavior attached.