confirm_boolean

Some settings are cheap to turn on and expensive to turn off. Valuing stock per lot or serial number is one: while it is on, each lot carries its own cost, and turning it off collapses all of them to a single value. The individual costs are not recoverable afterwards.

This widget is the toggle for that setting, with a confirmation in front of the destructive direction. Switching it on behaves like any other toggle. Switching it off opens a dialog naming the consequence and waits for an answer.

Once confirmed, it does something a plain toggle does not: it writes the change and saves the record in the same operation. A setting this consequential should not be left sitting unsaved on a form where it might be discarded by accident or applied by surprise later.

Confirmation dialogs are usually a sign that something is designed badly, but not always. Where an action genuinely loses information and cannot be undone, the dialog is the cheapest available safeguard, and the important part is that it names the consequence rather than asking a generic question.

The immediate save is the other half. A destructive setting that stays pending on a form creates a window where the record's state and the screen disagree, and where a later save applies a change nobody remembers making. Committing at the moment of confirmation closes that window.

The pattern generalizes to any irreversible switch: guard one direction, name the consequence, and commit on confirmation. What does not generalize is this particular widget, because the field it checks is written into the source.

The core usage

<field name="lot_valuated" widget="confirm_boolean"
       invisible="tracking == 'none'"/>

The field and the guard coincide, which is the only configuration in which the widget behaves as intended. It is hidden when the product is not tracked at all.

What happens on confirmation

# written and saved in one operation
record.update({ lot_valuated: false }, { save: true })

Not left pending. Cancelling writes nothing at all.

The plain toggle

<field name="lot_valuated" widget="boolean_toggle"/>

Same appearance, no warning and no immediate save.

The change handler is the whole widget. It builds a small function that writes the new value with saving switched on, then decides whether to call it directly or behind a dialog. The dialog is shown only when the guarded field is currently true and the new value is false, so turning the setting on is never interrupted.

Cancelling supplies an empty callback, which means nothing is written and the toggle returns to its previous state on the next render. There is no partial state to clean up.

The widget also substitutes a checkbox subclass. That subclass prevents the default action on every click and then only forwards the change when the click landed on the input element itself, which stops clicks on the surrounding label or padding from toggling a setting this consequential.

Two limits are worth stating for anyone tempted to reuse it. The guarded field is read by literal name, so the widget is bound to one setting rather than to whatever field it renders. And the warning text is fixed, so the consequence it names is specific to lot valuation.

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.

Byte-identical. The file on the development branch matches Odoo 19 exactly, including the hardcoded field name and warning text.