sol_product_many2one

Picking a product on a quotation looks like filling a many2one, but what happens next depends on the product, and this widget is the dispatcher. After a selection it asks the server, via get_single_product_variant, what kind of template was chosen. A template with exactly one variant and no options resolves silently to that variant. A configurable template opens the product configurator for attributes, custom values and optional products. A combo product opens the combo configurator, and if every combo slot has a preselected item it skips the dialog and saves directly. With the matrix module installed, matrix-mode templates open the order grid instead.

The widget inherits from product_label_section_and_note_field, which is why the same cell also renders section and note rows and merges the product name with the editable description underneath. On top of that it layers sale-specific labeling: the translated product name is stripped from the description display so salespeople read the name once, in their language, and combo lines show the quantity glued to the name, as in Lunch Combo x 3.

Configured lines grow an Edit Configuration button that reopens the right dialog with current attribute values, custom inputs fetched back from the server when needed, and combo selections reconstructed from the linked lines.

This widget is the front door of CPQ in Odoo, and its behavior decides how fast quotes go out and how clean they arrive.

The silent paths are the productivity feature. Single-variant products and fully preselected combos never show a dialog, so a rep quoting standard items keeps typing without interruptions. Dialogs appear exactly when a human decision is required. If your reps complain about popups on every line, the products are configured as configurable when they should not be, a catalog problem this widget faithfully exposes.

Optional products are a built-in upsell step. When a configurable product carries optional items, the configurator offers them and inserts accepted ones as their own lines directly beneath the main product. Teams that maintain optional product lists on their templates get attach-rate lift for free.

Locked orders stay navigable. Once an order is locked or the line list is readonly, the product cell turns into a link that opens the product form, so service and finance can still inspect what was sold. That is a deliberate design decision in the widget, not an accident.

When quoting flows need custom steps, price rule popups, engineering checks, bundle logic, the extension points are here: empty hooks like _onProductUpdate and the additional-props methods exist precisely for modules to override, which is how event tickets and rentals plug in. Extending them is core Odoo development for us.

How core uses it (quotation order lines, simplified)

<field name="order_line" widget="section_and_note_one2many">
    <list editable="bottom">
        <field name="product_template_id"
               widget="sol_product_many2one"/>
        <field name="product_id"
               widget="sol_product_many2one"
               optional="hide"/>
    </list>
</field>

Core mounts the widget on the template column by default and keeps the variant column hidden; the widget detects which of the two it sits on through the field's relation and adapts, template mode is what triggers get_single_product_variant.

Blocking product creation from the quote

<field name="product_template_id"
       widget="sol_product_many2one"
       options="{'no_create': True}"/>

All standard many2one options pass through the inherited descriptor, and no_create is the one sales admins actually want: reps pick from the catalog instead of inventing products mid-quote.

Highlighting lines without a product

<field name="product_template_id"
       widget="sol_product_many2one"
       options="{'show_label_warning': True}"/>

Inherited from the label base: warns on label-only lines. The sale widget additionally forces the warning color on any non-section, non-note, non-downpayment line whose product is missing.

The internal-update guard is the widget's most copied trick. A useEffect watches the product id, but reacts only when the change was flagged as internal, set inside the m2o's update path just before the write. Changes arriving from server onchanges, from the configurator applying its result, or from record reloads do not re-trigger dialogs. Custom widgets that chain dialogs off field changes without such a guard loop; this is the reference implementation.

Applying a configuration is a parallel write. The save handler builds the main line's values, variant, quantity, no-variant attribute values, custom attribute values as o2m commands, and applies optional products by inserting new lines at the correct index, all with the unlocked update so multiple lines write in parallel. Discarding a fresh configurator deletes the just-created line instead of leaving a half-configured stub.

Combos keep their children linked. A combo line stores its selection in selected_combo_items as JSON, stamps new combo lines with a generated virtual_id, and re-sorts the order lines by sequence after saving so combo items sit under their parent. Switching a combo line to another product first clears the selection JSON, which is what removes the child lines.

Version history in four steps. 16: a plain Many2OneField subclass, class-registered, configurator logic already present. 17: descriptor style on the m2o. 18: rebased onto the label-and-section base, adding the merged product cell, plus the combo configurator with the combo product type. 19: field dependencies, translated-name handling and the parallel-write apply path. Each step changed the base class, so JavaScript patches against this widget rarely survive a major version, plan for it in an Odoo migration.

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 re-verified here after release.

The widget survives intact; the file does not. Registration name, descriptor spread, extractProps and all five field dependencies are unchanged, but the source moves from sale/static/src/js/sale_product_field.js into its own sale_product_field/ directory, and the configurator glue, applyProduct and friends, is extracted into a shared saleProductMixin patched onto the class. Prop declarations migrate to the typed-props API.

Who feels it: anyone importing from the old path or patching methods that moved into the mixin. XML views need nothing. If your customization overrides _getAdditionalDialogProps, _prepareNewLineData or the product-update hooks, re-target them against the mixin after the release and re-test the configurator flows.