section_and_note_text

Order and invoice line grids in Odoo hold three kinds of rows in one table: product lines, section headers, and free-text notes, distinguished by the display_type field on the line. The description column has to edit differently for each: a section title is one line of text, a note or product description can be several.

section_and_note_text is the component that makes that decision. Its entire logic is a getter choosing which standard widget to render: CharField when the record's display_type is line_section, TextField otherwise. The list registration refines the fallback to the list-optimized ListTextField so multiline editing behaves inside the grid.

Its descriptor is the most minimal in this series: a component and a CSS class, no options, no supported types, no extractProps. Configuration happens entirely through the data.

Sections and notes are how a quotation stops being a parts list and starts being a proposal: phases with subtotals, scope descriptions between lines, terms embedded where they apply. Sales teams live in this structure daily, which makes its editing behavior part of the selling experience: a section header that suddenly grew a huge multiline editor, or a note squeezed into one line, breaks the rhythm of building a quote.

For customizers the widget matters mostly as a boundary marker. If you are changing how the description cell edits, this is your widget. If you are changing anything structural, section subtotals, collapsing, where the Add a section button inserts, you are in the companion one2many widget's territory (a page we cover separately when it enters the inventory; the widget lives in the same source file). Knowing the boundary saves hours of reading the wrong component.

How core uses it (order line grid)

<field name="name"
       widget="section_and_note_text"
       optional="show"/>

Inside a one2many whose parent field uses section_and_note_one2many, so the row types exist in the first place.

The data that drives it

{"display_type": "line_section", "name": "Phase 1: Discovery"}
{"display_type": false, "name": "Odoo implementation, 40 hours"}
{"display_type": "line_note", "name": "Travel billed at cost."}

Same field, three renders: single-line editor for the section, multiline for the product line and the note.

Most questions about section rows are actually questions about the companion widget, so here is the split, verified in the shared source file.

This widget owns the cell. Choosing char versus text editing for the description column is its entire job.

The one2many widget owns the rows. section_and_note_one2many extends the x2many list renderer with everything people associate with sections: hiding other columns on section rows via a colspan, the Add a section and Add a note buttons, section duplication and deletion cascading to their lines, drag-drop rules, and, new in 19.0, subsections and collapsible composition and prices driven by aggregated_fields, hide_composition, hide_prices and subsections attributes and options on the parent field.

The model owns the vocabulary. display_type values come from the line model. Adding your own row type means model work plus renderer work; this widget would only need touching if the new type should edit single-line.

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.

On the current master branch, this widget is gone: the section_and_note_text and list.section_and_note_text registrations and the SectionAndNoteText component are removed from section_and_note_fields_backend.js, and we found no other file in the master tree registering the name. The section machinery itself survives, section_and_note_one2many remains registered, and the description column's product-line duties sit with product_label_section_and_note_field, which master extends with new options. What this means practically: custom views that set widget="section_and_note_text" on a field will fall back to the field's default widget after an upgrade to 20, losing the per-row-type editor switch, and should be reviewed during migration. As always, the branch can still change before release.