name_with_subtask_count

In a task list, a parent task with eight children and a parent task with none look identical unless something says otherwise. This widget is that something: it renders the task name exactly like the char widget, then appends a muted counter, closed over total, in the form (2/5 sub-tasks), but only when subtask_count is nonzero.

The implementation is refreshingly small: a template inheritance that adds one span after the formatted value, and a descriptor that spreads the standard charField plus two fieldDependencies entries. Those dependencies are the interesting part: they tell the view machinery to fetch subtask_count and closed_subtask_count whenever the widget is present, so the counters arrive without anyone adding the fields to the view XML.

Sub-task counters change how teams read a backlog. A project lead scanning a list sees instantly which items are containers of work versus single actions, and the closed-over-total ratio doubles as a progress bar in four characters: (4/5) reads as "almost done" without opening anything.

The reason this page documents the widget's version history in detail is practical, not archaeological. Teams migrating custom task views from 16 or 17 regularly file "the sub-task counter disappeared" tickets, and the cause differs by version: in 16 the whole mechanism was a different server-computed field, and in 17 a one-letter typo in the source meant the counter silently depended on the view happening to include the count fields. Knowing which regime your custom views were built against turns a confusing UI regression into a five-minute fix.

How core uses it (task list)

<field name="name"
       widget="name_with_subtask_count"
       string="Title"/>

No options, no extra fields in the XML. The dependencies mechanism fetches both counters behind the scenes.

What renders

Prepare launch checklist  (3/7 sub-tasks)

The suffix is a muted span, present only when subtask_count is truthy; tasks without children render exactly like a plain char field.

The 17.0 typo deserves its own section because it is invisible unless you diff the file across versions, and it explains real-world behavior differences.

In 17.0 the descriptor key reads fieldsDependencies, with an extra s. The view machinery looks for fieldDependencies, so the declaration was ignored: the counters were not auto-loaded, and the counter span only rendered on views that happened to include subtask_count and closed_subtask_count anyway. Core's own views mostly did, which is why the bug shipped unnoticed.

18.0 fixed the spelling, and from there the widget behaves as designed: drop it on the name field and the counters come along automatically. The 18.0 and 19.0 files are identical apart from the module pragma, and the master branch carries 19.0's file unchanged.

16.0 is a different widget wearing the same name. It rendered a server-computed child_text string (something like "5 sub-tasks") gated by an allow_subtasks feature flag, with no closed count at all. Custom views ported straight from 16 therefore need the underlying fields rethought, not just the widget name kept.

Odoo 20 is expected at Odoo Experience in Brussels, 24 to 26 September 2026. The development branch is unstable until release, and we re-verify this page against the shipped version.

For this widget the branch currently shows no change: the 19.0 file is carried as is, dependencies, template and registration included. Whatever Odoo 20 does to the underlying char widget will flow in through the descriptor spread automatically.