many2many_alt_pos

Asking several suppliers for the same thing produces several quotations that only make sense next to each other. Odoo links them as alternatives, and every one of them shows the same list, including itself.

That self-inclusion is what this widget handles. Its renderer knows which row is the record you are currently on and marks it, so the list reads as a comparison rather than as a set of unrelated documents. Clicking that row is a no-op, because reopening the page you are on would only clear your place.

Clicking any other row opens it properly: the widget asks the server for that record's form action and navigates there in the same window, so the breadcrumb keeps the chain of quotations you have been comparing.

Comparing quotations is a decision process, not a lookup, and it happens by moving back and forth between documents. Preserving the breadcrumb is what makes that bearable, because the buyer can walk back through the ones they have already seen rather than starting from the list each time.

The self-marking matters for the same reason. Without it, a list of five quotations that all look identical gives no clue which one you are reading, and the usual result is opening the one you are already on and losing your place.

The structural note for anyone planning an upgrade is that this feature moves house in the next version: alternatives are being separated from blanket orders into their own module. The widget name survives, but any dependency declared on the old module needs revisiting.

The core usage, trimmed

<field name="alternative_po_ids"
       widget="many2many_alt_pos"
       readonly="not id"
       context="{'quotation_only': True}">
  <list> ... </list>
</field>

The read-only guard keeps alternatives from being linked before the order exists, and the context restricts the selection to quotations.

Restricting how alternatives are added

<field name="alternative_po_ids"
       widget="many2many_alt_pos"
       options="{'no_create': True}"/>

Forwarded to the embedded list as a CRUD setting, so alternatives can only be linked from existing orders.

What clicking does

# for any row that is not the current record
get_formview_action(record)  # asked of the server
doAction(action)             # same window, breadcrumb extended

Asking the server means a custom form view for purchase orders is respected rather than bypassed.

Three overrides, each one line of intent.

The renderer gains a test comparing each row's database id with the id of the form's root record. That is what lets its row template mark the current document, and it is the only thing the renderer subclass exists for.

The field component overrides the check for whether the relation is a many-to-many, always returning true. Without that, the framework would treat the field according to its declared type and could offer to create and delete rows, which for alternatives would mean creating purchase orders from inside a list.

The open handler is the substantial one. It first checks that the clicked record is not the one already open, and returns immediately if it is. Otherwise it calls the server for that record's form view action, passing the field's context, and hands the result to the action service. The source comment states both intentions: avoid reopening the current record, and open in the same window with the breadcrumb extended.

Asking the server for the action rather than constructing one is the detail worth copying. It means a database with a customized purchase order form gets that form, and any window action configuration such as view modes or context defaults is honored.

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 moves module. On the development branch the file and its view are in a new purchase alternatives module rather than the blanket order module, while the registered widget name is unchanged.

What that means in practice. View XML naming the widget keeps working, provided the new module is installed. Custom modules that depend on the blanket order module purely to get this feature should depend on the new one instead, and inherited views targeting the old module's view identifiers will need to be repointed.