integer_update_flag

Some numbers on a record are inherited from a global setting until somebody decides otherwise. A default time limit, a default lead time, a default threshold. The moment a user types their own number, that record should stop following the global default, and it should start following it again if they type the default back.

Odoo cannot detect that with a compute, because a compute cannot see who wrote the value. integer_update_flag can, because it lives inside the input. It renders as an ordinary integer field, and when the input fires its change event it compares what is now displayed against a reference value taken from the field's context, then writes the result of that comparison into a second boolean field.

Its sibling boolean_update_flag does the same for checkboxes. The two are written differently: the checkbox version overrides the component's onChange method, while this one attaches a listener to the raw input element, because an integer field's value is committed by a shared input hook rather than by a method the widget owns.

The value of this pattern is that a settings change stops being frightening. An administrator can raise the default time limit and know that only the questions nobody customized will move. Without the flag the choice is between overwriting everyone's work and never being able to change the default again, and teams usually pick the second, which is how stale configuration accumulates.

Two limitations belong in the project plan rather than in a support ticket later. The comparison happens in the browser, so nothing that arrives through an import, the API or an automation rule updates the flag. And the flag is a plain boolean on the record, so it can be corrected server side when a bulk operation gets it wrong.

If your override values can run into the thousands, read the deep dive before you deploy. The comparison has a formatting bug that makes large numbers unreliable, and the workaround is a one-line option.

The core usage, trimmed

<field name="is_time_customized" invisible="True"/>
<field name="time_limit" nolabel="1"
       widget="integer_update_flag"
       options="{'flagFieldName': 'is_time_customized'}"
       context="{'referenceValue': survey_session_speed_rating_time_limit}"/>

Both this field and the checkbox next to it write the same flag, so either one being customized marks the question.

Making large values compare correctly

<field name="threshold" widget="integer_update_flag"
       options="{'flagFieldName': 'threshold_overridden',
                  'enable_formatting': False}"
       context="{'referenceValue': default_threshold}"/>

Turning formatting off removes the thousands separator, which is what breaks the comparison above 999. Verified in the source, see the deep dive.

With inherited numeric bounds

<field name="threshold" widget="integer_update_flag"
       options="{'flagFieldName': 'threshold_overridden',
                  'type': 'number', 'min': 0, 'max': 600}"
       context="{'referenceValue': default_threshold}"/>

min and max come from the base integer widget and are passed to the HTML input, so they only constrain anything when type is number.

The comparison line in the source is parseInt(this.formattedValue) !== this.props.referenceValue, and formattedValue is the getter the integer widget uses to fill the input. Unless formatting is disabled, that getter returns a localized string produced by formatInteger, which inserts thousands separators.

parseInt stops at the first character it cannot read. In an English locale parseInt("1,200") returns 1. So a user who types 1200 into a field whose reference value is 1200 gets 1 compared against 1200, the values differ, and the record is flagged as customized even though it matches the default exactly. The mirror case is just as bad: two different four-digit values can both reduce to the same leading digit and fail to flag.

Below 1000 nothing separates, which is why the core usage never trips over it. Survey time limits are seconds, and questions are rarely given a twenty-minute limit. Any reuse with larger numbers should pass enable_formatting: False, which makes formattedValue return the raw number and the comparison exact. Human-readable formatting is worse still, since it renders values as text like 1k.

The other structural detail is how the widget hooks the change. It cannot simply override a method, because an integer field's value is committed by the shared input hook rather than by the component. So it takes a reference to the input element and adds its own native change listener, cleaning it up when the element goes away. That is also why it reads the displayed string instead of the record value: at that point the string is what the widget has.

Odoo 20 is expected at Odoo Experience in Brussels, 24 to 26 September 2026. The development branch is unstable, so read the following as direction rather than commitment; we re-verify this page after release.

Same behavior, tidier plumbing. The manual reference plus effect is replaced by a listener hook, and the props move to the new Owl schema syntax. The option key, the context key and the comparison line are unchanged, which means the thousands-separator behavior described above is still present on the development branch.

The core usage in the survey question form also survives unchanged.