sol_text

The description column on a quotation line does three jobs. On a product line it holds the product's description, which is often several lines. On a section or note row it holds the section title or the note text, and the row has no product at all. And since Odoo 19, on a combo line it holds the combo's label.

The first two are handled by the shared section and note text cell that invoices and purchase orders also use. This widget adds the third: when the line is a combo, it renders a single line input instead of the multi-line one.

That is the entire difference. Everything else, including how section and note rows are detected and rendered, comes from the shared cell it extends.

The distinction matters because a combo header is not a description. It is a short label naming the bundle, and giving it a growing multi-line box invites people to write a paragraph there, which then renders awkwardly on the quotation the customer sees.

It is a small example of a broader principle in document line design: the same column can mean different things on different row types, and the interface should reflect that rather than offering the widest possible editor everywhere. Odoo does the same thing for sections and notes; combos are simply a third case.

The core usage

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

Inside the order lines list, alongside the product picker. The list variant is selected automatically by the view type.

The two registrations

# both point at the same behavior
sol_text        # used outside a list
list.sol_text   # used inside a list view

Odoo resolves the prefixed name first when the field is inside a list, which is how the cell gets list-appropriate rendering.

The shared cell instead

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

What invoice and purchase lines use. Identical except that a combo line would get the multi-line editor.

The implementation is a single getter on each of two classes. The getter asks which component should render the cell: if the row's product type is a combo, it returns the single line text component, otherwise it defers to the parent's answer, which already handles section rows, note rows and ordinary product lines.

Two classes exist because the shared cell itself has two variants, a general one and a list one, and each has to be extended separately. They are registered under the plain name and the list-prefixed name respectively, which is Odoo's mechanism for giving a widget different behavior inside a list without changing the name used in the view.

Because the decision is made in a getter, it is re-evaluated on every render. Changing a line's product from an ordinary product to a combo therefore switches the editor immediately, with no reload.

The Odoo 20 development branch retires this widget. The description column moves to a new widget with a different name, living in its own file, and no registration under the old name remains. A view still naming it will fall back to the plain text field, losing both the combo behavior and the section and note handling, which is a more visible regression than most renames.

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 the page after release.

The widget is gone. There is no registration under this name on the development branch, and the core sale order view has moved the description column to a new widget in its own file, passing the partner through context.

Plan for the rename. Because the fallback for an unknown widget name is the field's plain type widget, a view left unchanged would render the description as an ordinary text box, losing the section and note behavior as well as the combo handling. Search custom order line views for this name before upgrading.