[17.0][FIX] website_sale_product_multi_website: avoid dropping websites

[pilarvargas-tecnativa]

Avoid replacing website_ids from the website_id inverse.

In this addon, website_ids is the source of truth and website_id
is kept as a computed compatibility field containing the first assigned
website.

The previous inverse replaced the full website_ids relation with the
single website_id value. This could silently drop website assignments
when editing website_ids or when legacy code wrote directly on
website_id.

Make the inverse non-destructive by adding the written website_id to
website_ids instead of replacing the whole relation.

@Tecnativa TT61624

@pedrobaeza @victoralmau please review

[pedrobaeza]

I don't think this is the solution, but to inhibit the write back. Try overriding write/create, and removing website_ids value if website_id is there in the dict.

[pilarvargas-tecnativa]

I don't think this is the solution, but to inhibit the write back. Try overriding write/create, and removing website_ids value if website_id is there in the dict.

I'm testing the real case and I don't fully understand the approach of removing website_ids when website_id is also present in vals.

The actual values reaching write are something like:

{
"website_id": 1,
"website_ids": [[4, 2]],
}

If we remove website_ids, we are left with:

{
"website_id": 1,
}

and since website_id has an inverse, it writes back to website_ids with only that single website. So we end up losing website 2 and keeping only website 1.

Since the whole purpose of this addon is to manage multiple websites through website_ids, my understanding is that in this conflict website_ids should take precedence over website_id.

Maybe you meant removing website_id from vals when both fields are present, in order to avoid triggering the destructive inverse write-back?

[pilarvargas-tecnativa]

There is another case that worries me about keeping the inverse as it is.

Removing website_id from vals when website_ids is also present fixes the issue when editing website_ids through this addon, because we give priority to the multi-website field.

However, if another module or any external code writes only to website_id, for example:

product.write({"website_id": website.id})

then the inverse is still executed and replaces website_ids with that single website.

This means products configured for multiple websites could become silently misconfigured, because a legacy write on website_id would remove the remaining website assignments from website_ids.

So if we want to keep the inverse for compatibility, I think it should at least be non-destructive and add the website to website_ids instead of replacing the whole relation.

[pedrobaeza]

Thanks for the insights. Let's change the inverse then, and do that the website_id written, to be added to the m2m, so that we fix both cases.

[pilarvargas-tecnativa]

Thanks for the insights. Let's change the inverse then, and do that the website_id written, to be added to the m2m, so that we fix both cases.

done! thanks