boolean_update_flag

Odoo has no ordinary way to know whether a field changed because a person edited it or because the server recalculated it. A compute or an onchange writes to the record exactly like a user does, and by the time the value lands nothing remembers where it came from. Most of the time that does not matter. Occasionally it matters a lot.

The case core built this widget for is survey questions. A live session has a default time limit set on the survey; each question may override it. Odoo needs to know which questions were deliberately customized, so that changing the survey default updates the untouched ones and leaves the customized ones alone. A compute cannot answer that. A widget can, because it sits exactly where the human click happens.

So boolean_update_flag renders as a normal checkbox and adds one behavior: when the user toggles it, the widget compares the new value with a reference value taken from the field's context and writes the result of that comparison into a second boolean field. Different means customized, same means back to default.

The pattern this widget implements is worth recognizing outside surveys, because it appears constantly in configuration screens: a global default, per-record overrides, and the need to know which records are overridden. Without that knowledge, changing the default either silently overwrites everyone's careful settings or refuses to touch anything, and both make users distrust the setting.

The comparison is symmetric, which is the detail people miss. Setting the value back to the default clears the flag, so a record does not stay marked as customized forever after one accidental click. Users can undo their own override without an administrator.

The cost is that this logic lives in the browser. Data imported by CSV, changed through the API, or written by an automation rule never passes through the widget, so the flag will not be updated. If your process depends on that flag being right for imported data, the comparison has to be repeated server side. Plan for that rather than discovering it after a migration.

The core usage, trimmed

<field name="is_time_customized" invisible="True"/>
<field name="is_time_limited" nolabel="1"
       widget="boolean_update_flag"
       options="{'flagFieldName': 'is_time_customized'}"
       context="{'referenceValue': survey_session_speed_rating}"/>

The flag field must be present in the view, and the reference value is an ordinary field expression evaluated in the record's context.

Reference value from a plain literal

<field name="send_reminder" widget="boolean_update_flag"
       options="{'flagFieldName': 'reminder_overridden'}"
       context="{'referenceValue': True}"/>

Legal and useful when the default is fixed rather than read from a parent record.

What does not work

<!-- snake_case key: ignored, then a props error -->
<field name="send_reminder" widget="boolean_update_flag"
       options="{'flag_field_name': 'reminder_overridden'}"/>

The extractor reads only options.flagFieldName. Anything else leaves the prop undefined, and the prop is required.

The class is eleven lines. It extends the standard BooleanField, declares two extra props and overrides onChange. The override calls super.onChange first, so the checkbox's own value is written exactly as it always was, then performs a second write: record._update({ [flagFieldName]: newValue !== referenceValue }).

Two details in that line are worth pulling out. The method is _update, the record's internal update, not the public update. The practical effect is that setting the flag does not itself trigger a server onchange round trip, which keeps the widget from re-entering the very machinery it was written to distinguish itself from.

The comparison is a strict inequality, so the reference value's type matters. The context expression is evaluated as Python, then reaches the prop declared as a boolean. A reference value of 1 rather than True will fail the props type check instead of quietly comparing wrong, which is the friendlier of the two failure modes.

The source docstring states the intent plainly: this behavior is enabled only when a user directly changes the value from the client, and not as a result of another onchange or compute. That sentence is the whole design rationale, and it is also the limitation. Nothing outside the browser sets this flag.

Odoo 20 is expected at Odoo Experience in Brussels, 24 to 26 September 2026. The development branch is unstable and the notes below can still change; we re-verify this page once Odoo 20 ships.

No behavior change. The option key, the context key, the comparison and the use of the internal update path are all identical. The only difference is the migration to the new Owl props syntax, where the two props are declared with the schema helpers instead of the old static props object. That affects JavaScript that patches the widget, not view XML.

The core usage also survives: the survey question time limit block still uses the widget on the development branch.