customContentKanbanLikeWidget

A quotation that goes out as a PDF is often more than the order lines: a cover page, terms, a product datasheet per line, a signature page. The PDF quote builder assembles those from documents attached to templates and products.

This widget is the picker for that assembly. It shows three groups of cards, headers, per-line documents and footers, each selectable, and each able to carry form fields whose values you fill in here.

All of that, the selections and the field values, is serialized into one JSON field on the quotation, which is what the PDF generation later reads.

Quote presentation is a real differentiator in considered purchases, and the practical obstacle is that assembling a good-looking PDF by hand does not scale past a few quotes a week. Making it a card grid does.

The thing to invest in is the document library. The widget only offers what the template and the products provide, so the quality of the output is decided before anyone opens a quotation.

Placing it

<widget name="customContentKanbanLikeWidget"/>

No attributes. It reads the quotation and its lines.

What is stored

{ header: {...}, line: {...}, footer: {...} }
# serialized into one field on the quotation

Document names and their form field values.

When it refetches

# whenever the quotation template changes

Because that changes which documents apply.

Two behaviors here are unusual enough to be worth calling out.

The first is how a line document selection is written. The widget finds the order line record, sets a flag on it that prevents the parent from being updated, then links or unlinks the document with an immediate save. The source explains both: the flag stops a network call to save the parent, and the immediate save stops a change handler from firing. The line relation is then updated once, explicitly without change handlers.

That is three separate suppressions in one method, and the reason is volume: a quotation with twenty lines and a document each would otherwise trigger a cascade of server round trips.

The second is the confirmation behavior. An effect watches the quotation's state, and when it becomes confirmed the widget sets its own read-only prop and saves the record to force a refresh. Writing to a prop is unconventional; the effect is that a confirmed order's PDF composition freezes.

The serialization itself is mechanical: selected headers and footers, and per line the selected documents, each reduced to a name and a map of form field values, all merged into one object and written to the quotation's JSON field.

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.

Reworked. The development branch changes the component alongside the newer state conventions. The three card groups and the single JSON field are what to expect to survive.