task_done_checkmark

Marking something done is the most common single action in a project tool, and it happens in two different situations. Ticking items off a list is a rapid, repeated action with no intention of editing anything else. Setting the flag on a form is part of a larger edit that ends with a save.

This widget renders the flag as a checkmark rather than a switch, which suits completion better than an on and off setting, and then adapts to those two situations. In a list or a kanban, clicking writes and saves at once. On a form, clicking updates the record and leaves the save to the user.

Everything else about the value comes from the toggle widget it extends. The difference is entirely in the visual and in that one decision.

The saving rule is the part worth knowing, because it explains behavior that otherwise looks inconsistent. A user who ticks five milestones in a list expects them to stay ticked without pressing anything, and a user who ticks one on a form expects to be able to discard it along with the rest of their edit. Both expectations are correct, and the widget serves both.

The general lesson is that immediacy should follow the surface, not the field. A widget that always saves is wrong on forms, and one that never saves is wrong in lists. Reading the view type is a small amount of code for a noticeable improvement in how the interface feels.

The core usage

<field name="is_reached"
       widget="task_done_checkmark"
       class="oe_inline"/>

No options. Whether the click saves depends on which view the field is rendered in.

In a list

# clicking writes and saves in one operation
record.update({ is_reached: true }, { save: true })

Which is what makes ticking through a list of milestones feel immediate.

On a form

# clicking updates only; the form save applies it
record.update({ is_reached: true })

So the change can be discarded along with any other edits.

The change handler is the widget. It computes the inverted value, then branches on the view type taken from the environment configuration: for a list or a kanban it updates with saving switched on, and for anything else it updates without.

Reading the view type from the environment rather than from a prop is what lets the same field element behave correctly in both places without the view author choosing. It also means the behavior is not overridable from XML, which is deliberate.

The other detail is how the current state is exposed to the template. Odoo 19 keeps a small piece of local state and refreshes it on every render, which works but is more machinery than the job needs. The development branch replaces it with a plain getter reading the record directly, which is both simpler and immune to the state drifting out of step with the record.

Everything else is inherited, including the underlying value handling and the toggle's own options. The widget contributes a template and one branch.

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.

The saving rule is unchanged. Lists and kanbans still save on click and forms still do not.

The state handling is simplified. The local state refreshed on every render is replaced by a getter reading the record directly, which removes a small opportunity for the displayed tick to disagree with the stored value.