notebook_task_one2many

A notebook tab is a constrained space: it sits under a form's header, shares width with everything else, and is usually one of several tabs competing for attention. A task list rendered there needs different column choices and different density from the same list on its own screen.

This widget supplies that, by swapping in a renderer written for the notebook layout. The list of tasks itself is ordinary; what changes is how it is drawn inside the tab.

It also makes one behavioral adjustment. When the tab shows tasks as kanban cards, clicking a card is routed through the switch to the form view, so it navigates to the task rather than opening it in a dialog on top of the current record.

Related tasks shown on a parent record are a navigation aid, not a workspace. Treating a card click as navigation rather than as a dialog reflects that: the user wants to go to the task, not to edit it in a popup while the parent sits behind.

Where this matters practically is choosing between the two similar Project widgets. This one and the sub-tasks widget look interchangeable and are not, because only the sub-tasks widget filters the parent's context. On a list of tasks that are not children of the current record, passing the context through is usually what you want; on true sub-tasks it usually is not.

The core usage, trimmed

<notebook>
  <page string="Tasks">
    <field name="task_ids"
           widget="notebook_task_one2many"
           mode="list,kanban"/>
  </page>
</notebook>

Both view modes work, and the kanban mode is where the opening behavior differs.

Presetting new tasks

<field name="task_ids"
       widget="notebook_task_one2many"
       context="{'default_project_id': id}"/>

Context passes through unfiltered, so defaults and anything else both apply.

The sub-tasks alternative

<field name="child_ids" widget="subtasks_one2many"/>

Similar list, but the context is filtered before a record is opened.

The widget is twenty lines and does two things: it substitutes the notebook renderer, and it overrides the renderer properties so that in kanban mode the open handler becomes the widget's own switch to the form.

That override is conditional on the view mode, which is worth noting because it means the same field element behaves differently depending on which subview is showing. In list mode nothing is changed, so a row opens the way any embedded list row does.

The absence of context filtering is the more consequential difference, and it is an absence rather than a decision written in code, so it is easy to miss when comparing the two Project list widgets side by side. If a task opened from a notebook tab inherits something unexpected, the parent screen's context is where to look.

Everything about how the list is drawn belongs to the substituted renderer rather than to this file, which is why the widget itself carries almost no logic.

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 conditional kanban handling.