product_label_section_and_note_field_o2m

The lines grid on an invoice looks like an ordinary embedded list, but it is doing three unusual things at once, and this widget is the assembly point for all of them.

First, it inherits the section-and-note machinery: rows whose display_type is line_section or line_note drop their cells and render as full-width bold headings or italic notes, which is how quotations and invoices get their document-like structure. Second, a mixin patched in from the product module merges the product and its description into one cell, the label logic that shows the product name with the editable description under it. Third, and unique to this widget, the renderer rewrites the column layout at render time depending on what kind of document the parent is.

That last part is the reason this subclass exists. Columns marked optional="conditional" in the XML, Product, Quantity and Unit on the invoice form, are resolved dynamically: on a vendor bill the Product column defaults to hidden, because bills are often line-item text captured from a PDF, and on a customer invoice all three default to hidden when the Sale app is not installed, on the theory that an accounting-only database invoices in prose, not SKUs. Users can still reveal the columns from the optional-columns dropdown; the widget only changes the default.

This widget is why a vendor bill screen feels different from a customer invoice screen without anyone configuring anything. Odoo is making a workflow assumption on your behalf: bills get typed or OCRed as text lines, invoices carry products only when there is a sales pipeline feeding them. For most companies the defaults are right, and knowing they are just defaults, every hidden column is one click away in the list's optional-columns dropdown, saves teams from filing bugs about missing Product columns.

The section and note rows are worth actual process attention. Finance teams that structure long invoices with sections, phases, milestones, retainers, produce documents clients approve faster, and since the same renderer family drives quotations and purchase orders, the structure carries through the quote-to-invoice chain. If your invoices come out of a custom flow, making that flow emit proper line_section rows rather than fake text lines is a small change with visible payoff.

When the defaults are wrong for you, a services company that wants products on bills, or a distributor that needs quantity visible everywhere, the fix is a view inheritance changing optional="conditional" to optional="show", typical Odoo customization territory, minutes not days.

How core uses it (invoice form, simplified)

<field name="invoice_line_ids"
       widget="product_label_section_and_note_field_o2m">
    <list editable="bottom">
        <field name="product_id" optional="conditional"/>
        <field name="name" widget="section_and_note_text"/>
        <field name="quantity" optional="conditional"/>
        <field name="product_uom_id" optional="conditional"/>
    </list>
</field>

The parent form must expose move_type and is_sale_installed; the renderer reads both from the eval context to resolve the conditional columns.

Using the hidden section options

<field name="invoice_line_ids"
       widget="product_label_section_and_note_field_o2m"
       options="{'subsections': True, 'hide_prices': True}"/>

subsections enables the two-level section hierarchy (line_subsection rows render semibold under their bold parents), and hide_prices suppresses price columns on section rows. Neither appears in any documentation; both are read straight from extractProps.

Aggregating custom columns on section rows

<field name="invoice_line_ids"
       widget="product_label_section_and_note_field_o2m"
       aggregated_fields="price_subtotal, margin"/>

aggregated_fields is an attribute, not an option: a comma-separated list of numeric columns the section rows should subtotal for the lines beneath them.

The conditional-column algorithm, verbatim from the source. For every column whose optional attribute equals conditional and whose name is product_id, quantity or product_uom_id (a hardcoded whitelist), the renderer starts from show, then applies two rules: if parent.move_type is a purchase type (in_invoice, in_refund, in_receipt) the product_id column flips to hide; if it is a sale type (out_invoice, out_refund, out_receipt) and parent.is_sale_installed is false, all three flip to hide. The result feeds the normal optional-columns mechanism, so user preferences stored per view still win afterward.

Readonly styling is deliberately relaxed. isCellReadonly is overridden for the product columns and the label column: even when the base renderer computes readonly, the cells only get the readonly classes when the parent document is posted, cancel or locked. The comment in the source is explicit that this exists to stop readonly styling from appearing on cells that are in fact still editable, a purely visual override with no security meaning.

The mixin does the label magic. ProductNameAndDescriptionListRendererMixin is patched onto the renderer prototype at module load. It is the same code that powers the sale order grid, which is why product cells behave identically on quotations and invoices: name on top, description folded beneath, with product_id and product_template_id as the recognized product columns.

Odoo 20 is expected at Odoo Experience in Brussels, 24 to 26 September 2026. Findings below are from the public development branch, unstable until feature freeze, and this page will be re-verified against the release.

The widget survives, its signature trick does not. On the development branch the registration, the descriptor spread and the readonly relaxation are all unchanged, but processAllColumn and the conditionalColumns whitelist are deleted outright. optional="conditional" therefore stops meaning anything to this renderer: bill and invoice column defaults will come from whatever the upgraded views declare, not from client-side document-type logic.

What to check in a migration: any view inheritance you built around optional="conditional", and any assumption that vendor bills hide the Product column by default. A one-line comment on the branch also confirms product_template_id stays a recognized product column for the sale and purchase grids. Our migration team tracks exactly this kind of silent behavioral change between versions.