task_stage_with_state_selection

Task lists in Odoo show more than the stage name in the Stage column: each row also carries the small task state icon, the checkmark, hourglass or cross that project_task_state_selection renders. This widget is the glue that puts both in one cell.

Structurally it is unusual. Most widgets on this site wrap one field; this one is a composite component whose template renders a Many2One for the field it is placed on, stage_id, and a ProjectTaskStateSelection for a second field it fetches itself. The second field's name is hardcoded: fieldDependencies declares state, and the state component receives name: "state" unconditionally.

The state part is passed showLabel: false, so it always renders as a bare icon, and by default it is also passed readonly: true through the widget's one option, which makes the icon informational in lists unless you opt in to editing.

The reason this widget exists is information density. A task list that shows only stages answers where work sits; adding the state icon answers how it is doing there, approved, changes requested, waiting, done, without an extra column eating horizontal space.

For teams running approval flows on tasks, the pairing matters day to day: a task can sit in the same stage for a week while its state moves from In Progress to Changes Requested to Approved. Reviewers scanning the list see that movement in the Stage column itself.

The default read-only state icon is a sensible guardrail in shared lists: it stops a stray click from flipping a task to Done while still showing the signal. Where a lead actively triages from the list, enabling the click with state_readonly: False turns the column into a working surface.

How core applies it in the task list

<field name="stage_id" invisible="not project_id or not stage_id"
       widget="task_stage_with_state_selection" filters="1"/>

The state field does not need to be added to the view; the widget's fieldDependencies pulls it into the record data automatically.

Making the state icon clickable

<field name="stage_id" widget="task_stage_with_state_selection"
       options="{'state_readonly': False}"/>

The dropdown then behaves exactly like project_task_state_selection: waiting tasks only offer Done and Canceled, and changes save immediately in list view.

What not to write

<!-- no_open is ignored: the descriptor never reads m2o options -->
<field name="stage_id" widget="task_stage_with_state_selection"
       options="{'no_open': True}"/>

Reading the source explains both the power and the constraints of the composite approach.

Two components, one record. The template is four lines: a flex div containing <Many2One t-props="stageProps"/> and <ProjectTaskStateSelection t-props="stateProps"/>. Both prop sets derive from the same standard field props, so both halves read and write the same record; the state half just swaps the field name to state and forces showLabel: false.

The 18 to 19 rewrite is internal only. Odoo 18 passed the props straight into the full Many2OneField component. Odoo 19 switched to the new composition API, computeM2OProps plus the lean Many2One component, part of the framework-wide many2one rework. The registered name, option and behavior are unchanged.

Why the m2o options are dead. Options only reach a widget through its descriptor's extractProps. This descriptor's extractProps returns exactly two props: stateReadonly and viewType. The stage half receives the computed defaults of the m2o machinery, which in 19 means the standard open-on-click and create behaviors, with no way to tune them from XML.

viewType is forwarded deliberately. ProjectTaskStateSelection changes behavior by view, saving immediately in lists and kanbans, so the composite passes the real view type through instead of letting the inner component assume a form.

Odoo 20 is expected at Odoo Experience in Brussels, 24 to 26 September 2026, and the development branch remains unstable until release.

The branch removes the state_readonly option entirely: supportedOptions is gone, extractProps forwards only the view type, and the state component no longer receives a readonly override, so the state icon is always interactive wherever the record itself is editable. XML passing {'state_readonly': ...} will not error, it will simply stop having any effect, flipping today's safe-by-default lists into clickable ones. Worth a note in your 20 migration checklist; we re-verify after release.