subtasks_one2many

Sub-tasks are tasks, which makes their list unusual: the child records use the same model as the parent, and the parent's screen is full of context keys meant for it rather than for them. Passed through unfiltered, that context can preset fields on a sub-task in ways nobody intended.

This widget is the sub-tasks list, and its characteristic behavior is that filtering. When a sub-task is opened, it builds a reduced context from the parent's: the flags that control whether archived records are visible and how that propagates, plus every default value key, and nothing else.

It also adapts to the kanban view. When the sub-tasks are shown as cards, opening one is routed through the switch to the form rather than the default record opening, so a card behaves like a link to the task.

Sub-task hygiene is where project structures either stay useful or collapse into a flat list. The context filtering matters because a sub-task that silently inherits a filter or a default from wherever the parent was opened is a sub-task nobody trusts.

The general point applies to any nested relation on the same model. Whenever a child list shares the parent's model, decide explicitly what context should travel; the default of passing everything is almost never what you mean.

The core usage, trimmed

<field name="child_ids" widget="subtasks_one2many"
       mode="list,kanban">
  <list editable="bottom"> ... </list>
</field>

Both view modes are supported, and the kanban mode changes how a card opens.

Presetting a sub-task

<field name="child_ids" widget="subtasks_one2many"
       context="{'default_project_id': project_id}"/>

Default keys survive the filtering, which is how a sub-task inherits the project.

What does not travel

# dropped when a sub-task opens
search_default_*, group_by, form_view_ref, ...

Only the two named flags and the default keys are kept.

The context filtering is a single method. It collects every key from the field's context that begins with the default prefix, then picks from the context exactly those keys plus two named flags: the one controlling whether archived records are included, and the one controlling whether that setting propagates.

Both of those matter for sub-tasks specifically. A parent task viewed with archived records visible should open its sub-tasks the same way, and the propagate flag is what carries that decision down another level.

The kanban adjustment is smaller but visible. When the embedded view is a kanban, the renderer's open handler is replaced with the widget's own switch to the form view, so clicking a card navigates rather than opening a dialog. In list mode the standard behavior applies.

Everything else, including the sub-task list's own rendering, belongs to the renderer this widget substitutes rather than to the widget itself, which is why the file is short.

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.

Byte-identical. The file on the development branch matches Odoo 19 exactly, including the filtered context and the kanban open handling.