section_one2many

section_one2many extends the standard embedded one2many table with exactly one swap: the list renderer becomes SectionListRenderer, a subclass that promotes certain rows to section headers. It also forces two defaults, inline editing at the bottom (editable: "bottom") and the o_field_one2many CSS class.

The renderer's contract, read from section_list_renderer.js, is precise. A row is a section when record.data.display_type === "line_section". Section rows get bold styling and an o_is_line_section class, drop every column except drag handles, and stretch one cell across the remaining width. That cell shows the field named title, a name hardcoded in the renderer.

The result is the working schedule editor every Odoo user has seen: Morning and Afternoon captions separating attendance lines, all stored in the same one2many.

Long line lists without visual structure are where configuration errors live. Working schedules are the canonical case: two weeks of attendance lines are unreadable until Morning, Afternoon and week captions split them. Sections give operational lists document like readability without leaving the record.

The pattern is reusable on custom models, order checklists, inspection protocols, onboarding step lists, provided you mirror the model contract: a display_type selection containing line_section and a char field named exactly title. It is a cheaper structure than splitting data into separate tabs or child models.

The working schedule usage from resource_calendar_views.xml:

<field name="attendance_ids" widget="section_one2many"/>

The two week schedule variant seeds each tab with a default via context:

<field name="attendance_ids_1st_week" widget="section_one2many"
       context="{'default_week_type': '0'}"/>

A custom model needs the contract fields before the widget does anything special:

display_type = fields.Selection([('line_section', 'Section')])
title = fields.Char()

Reading section_list_renderer.js answers the questions the working schedule form raises:

Why do section rows survive column changes? getSectionColumns rebuilds the row from scratch: it keeps only columns whose widget is handle, then appends the title column with a computed colspan covering everything else (plus one when the delete trash can is active). Add or remove columns from the embedded list and sections adapt automatically.

Why is the list editable without saying so? The widget's defaultProps set editable: "bottom", so new lines append inline even when the subview arch omits the editable attribute. An explicit arch value still wins.

How do sections get created? The widget adds no special Add a section control. Odoo's schedule views handle it with context defaults and server side logic; a bare custom view creates sections by adding a line with display_type set to line_section, typically via a context default on a dedicated button.

How does it differ from account's section lists? The account module ships its own section renderers (see product_label_section_and_note_field) keyed on the name field and supporting notes; this resource variant is leaner, sections only, caption field title.

Odoo 20 is expected at Odoo Experience in Brussels, 24 to 26 September 2026. The changes below are read from the public development branch and are not final until release.

The widget is deleted on master. Both section_one2many_field.js and its SectionListRenderer are gone from the resource module, and resource_calendar_views.xml no longer references the widget. The schedule editing views move to a new set of calendar oriented components (resource_calendar_attendance_calendar_one2many and related files). Custom views using widget="section_one2many" will fall back to a plain one2many after upgrading, losing their section rows silently, so this belongs on every 20 migration checklist.

We will re verify this page against the released branch after the launch.