todo_done_checkmark

Odoo's to-do app stores completion in the task state field, the same five-value selection project tasks use: in progress, changes requested, approved, canceled, done. A personal to-do does not need that machinery on screen; it needs one tick. This widget renders the whole selection as a single circled check that is hollow while the to-do is open and filled once it is done.

Under the hood it subclasses state_selection, so it is still a selection widget with all of that widget's props. What it overrides is presentation and the click. The template drops the dropdown entirely, desktop and mobile variants both render one anchor with a Font Awesome check-circle glyph and a tooltip that flips between "Mark as done" and "Mark as to-do".

The click is a toggle with memory: to done if the state is anything else, and back to the remembered previous state otherwise, so a to-do that was 02_changes_requested returns there when unticked rather than resetting arbitrarily.

For anyone running their day out of Odoo's to-do list, this widget is the interaction they touch most. Two of its details are worth knowing at the process level.

First, the save behavior differs by view. Ticking a to-do in the list or kanban writes immediately, which is what a checklist should do. Ticking it on the form is a pending edit, committed with the rest of the form. Users who tick and immediately navigate away from a form can lose the tick, and it looks like a bug when it is the standard form edit model.

Second, because the widget writes the shared task state field, done here means done everywhere. To-dos converted to project tasks, or tasks surfaced in the to-do app, carry the state across, and dashboards counting 1_done tasks include ticks made from this checkmark. That makes the humble circle a real data entry point, not a private flag, and it is why the revert behavior preserves the old state instead of guessing.

As core uses it in the to-do list

<field name="state" widget="todo_done_checkmark" nolabel="1" width="20px"/>

On the to-do form next to priority stars

<field name="priority" class="h3 pe-2" widget="priority_switch"/>
<field name="state" widget="todo_done_checkmark" class="o_task_state_widget"/>

This pairing is the whole to-do header UI in core: stars for priority, circle for done.

On a custom model

<field name="state" widget="todo_done_checkmark"/>

Works only if the selection actually contains a 1_done value and, for a sensible fallback, 01_in_progress; both value strings are hardcoded in the toggle logic.

The component keeps two flags of local state, and both exist to stop the icon from lying.

notDoneState is the memory. Captured once in onMounted: the field's current value, unless that value is already 1_done, in which case it falls back to 01_in_progress. This is what an unticked to-do returns to. Because it is captured at mount, a state changed elsewhere after load does not update the memory until the view rerenders the component.

notReloadState is the hover freeze. Mouseover sets it, mouseleave clears it, and while it is set the rendered done/not-done appearance refuses to sync with the record. The effect: as you click, the glyph under your cursor does not instantly flip and shift the layout; it settles when the mouse leaves. A tiny piece of UI craft entirely invisible in the docs.

The save split is one if statement. onDoneToggled calls the inherited updateRecord, which honors autosave and saves, only when viewType is kanban or list; otherwise it calls record.update, a pending edit. The viewType arrives through a custom prop the descriptor's extractProps adds, a pattern worth copying when a custom widget needs to know its host view.

Note the hardcoded strings: 1_done and 01_in_progress are literals in the source. This widget is not generic; it is welded to the task-state vocabulary.

Odoo 20 is expected at Odoo Experience in Brussels, 24 to 26 September 2026. These notes are read from the public development branch, which is unstable until feature freeze; we re-verify against the shipped release.

Two changes are visible. The immediate-save check swaps kanban for card, following the framework-wide kanban-to-card rename, so the widget saves immediately in card and list views. And the props migrate to the new validation system, with the component now spreading standardFieldProps plus optional showLabel, withCommand, and viewType.

Upstream of it, the base state_selection deletes its autosave option on master, which trims this widget's inherited option surface too. The toggle logic, the hardcoded state strings, and the hover freeze are all unchanged.