pavs_one2many

Product attribute values are referenced everywhere once they are in use: on variants, on order lines, in pricing rules, in historical documents. Deleting one that is still referenced is not a decision a user should be allowed to make casually, and in many cases not at all.

This widget guards that. When a value is deleted, it first asks the server whether the value is used on any product. If the server returns a reason, the widget shows it in an Invalid Operation dialog and stops. No confirmation, no deletion.

If the value is genuinely unused, the ordinary delete confirmation appears, and confirming unlinks the value on the server and then saves the attribute. A row that was only just added and never saved skips the whole check and is simply removed.

Attribute values are the sort of configuration that looks disposable and is not. Deleting a color that appears on three years of sale orders is a data integrity problem that surfaces slowly, in reports and reprints, long after anyone remembers making the change.

Putting the check in front of the confirmation rather than behind it is the right order. A user who is told why they cannot delete something learns the constraint; a user who confirms and then gets a server error learns only that the system is unreliable.

The immediate unlink is the trade. Confirming does not queue a change for the form's save, it writes straight away and then saves the attribute, so there is nothing to discard afterwards. On configuration data that is defensible, and it is worth telling whoever maintains your catalog.

The core usage

<field name="value_ids" widget="pavs_one2many"
       nolabel="1">
  <list editable="bottom"> ... </list>
</field>

No options. Everything the widget adds happens on the delete action.

What the guard calls

# on the attribute value model
check_is_used_on_products(value_id)
# a returned message means: refuse

The message is shown as-is, so the wording comes from Python rather than from the widget.

The ordinary child list

<field name="value_ids">
  <list editable="bottom"> ... </list>
</field>

Deletes without asking the server first, leaving the failure to surface as a constraint error on save.

The delete handler runs three checks in order, and the order is the design.

First it calls the server. If a message comes back, the value is in use, and the widget shows that message in a dialog titled Invalid Operation and returns. Nothing else happens, so the user is never offered a confirmation for something that cannot succeed.

Second it checks whether the row is new. An unsaved row has nothing on the server, so it defers to the standard behavior and the row is simply dropped.

Third, for an existing and unused value, it shows the ordinary delete confirmation. Confirming unlinks the record on the server, calls the standard delete handling, and then saves the attribute so the list and the record agree.

The Odoo 19 change is in how that confirmation is awaited. Odoo 18 opened the dialog and continued immediately, so the calling code did not wait for the user; Odoo 19 wraps it in a promise that resolves on confirm or cancel. Anything that awaited the delete now actually waits, which matters when several rows are removed in sequence.

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.

One cosmetic change. The delete confirmation's button gains a danger style on the development branch. The server check, the refusal dialog, the immediate unlink and the awaiting behavior are all unchanged.