subtask_kanban_list

On a kanban board, a task with sub-tasks is a task whose real status lives one level down. Showing the sub-tasks on the card is the difference between a board you can read and one you have to click through.

This widget does that, with two useful restrictions. It shows only the open ones, because a finished sub-task is not information anyone needs on a board. And each row carries a working state field, so a sub-task can be moved along without leaving the card.

It also creates. A small inline input adds a sub-task directly, inheriting the parent's project and assignees.

Boards stop being used when they stop being accurate, and the usual cause is that updating a status costs a navigation. Editable state on the card removes that cost for the level where most of the churn happens.

The inline creation is worth a word of caution in process terms: it makes adding a sub-task nearly free, which is good for capture and bad for scope if nobody prunes.

Placing it

<widget name="subtask_kanban_list"/>

Inside a kanban card template.

What is hidden

# states meaning done and canceled

Everything else is shown.

What a new sub-task inherits

parent, project, assignees,
sequence = highest + 1

Created directly, no form.

The caching getter is the part worth understanding. It compares the current record count against a remembered one; if they match and the initial load is done, it returns the previously filtered array untouched. Only a change in count triggers a refilter.

That is a real optimization on a busy board, and it has a visible consequence: closing a sub-task changes its state but not the count, so the row stays until something adds or removes a record. Reading the code is the only way to know that, which is why it is worth stating.

The state field is built at runtime rather than declared in a view. The widget assembles the field information itself, naming the selection widget used for task states and setting the view type, which is what allows a fully functional field to appear inside a widget that has no view definition of its own.

Creation is a direct record creation rather than a form. The sequence is computed as one above the highest currently present, so the new sub-task sorts to the bottom. The parent's project and assignees are copied across, and an empty name is refused with a notification before anything is written.

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.

Newer conventions, and a renamed view type. The development branch swaps the state hooks for their Owl 3 equivalents and changes the runtime field's view type from kanban to card, following the wider view renaming. The filtering and creation logic are unchanged.