boolean_toggle_load

Skill levels have a default: the level a skill is assumed to be at unless something says otherwise. Marking one level as the default is a toggle, and toggling it has consequences the server has to work out, because only one level per skill can hold that role.

The complication is the same one several Odoo widgets solve in different ways: the server cannot tell a user's toggle from a recomputation caused by another toggle. Both arrive as a write.

This widget answers it by writing a second field at the same time, carrying the same value, whose only job is to say that this change originated here. The comment in the source puts it plainly: the technical field tells the backend which level triggered the change.

The pattern matters more than the field. Any model where changing one row must adjust the others has this ambiguity, and solving it in the interface, by marking the origin of a change, is often simpler than trying to infer it server side.

What it means in practice for skills is that the default level behaves predictably: setting one clears the others, and the cascade does not fight itself. That is the kind of correctness nobody notices until it is missing.

The usual usage

<field name="default_level"
       widget="boolean_toggle_load"/>

Toggling writes both the field and the technical flag in one update.

What reaches the server

{ default_level: true,
  technical_is_new_default: true }

Two keys, one update, so the server can act on the origin as well as the value.

The plain list toggle

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

One key, and the server cannot tell which row the user actually touched.

The whole widget is one overridden change handler. It sets the component's local state, builds an update carrying two keys, and awaits it with the inherited autosave setting applied.

The two keys are the toggled field, taken from the widget's own field name, and a technical field named literally. Both get the new value, which is what lets the server treat the technical one as a marker rather than as data.

Because both go in a single update, the server sees them in the same write and can apply its cascade in one pass. Sending them separately would reintroduce exactly the ambiguity the technical field exists to remove.

The autosave option comes from the list toggle it extends, and in a list that normally means the change is committed at once, which is appropriate for a setting whose cascade should not sit half-applied.

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 this page after the release.

Behavior is unchanged. The paired write and the technical field name are the same on the development branch. The differences follow the wider component migration and affect patches rather than views.