[dnplkndll]

post-migration.py

Give every extra variant image back to a template, the way 20.0 holds it.

19.0 attached the image to one variant. 20.0 attaches it to the template and
works out which variants it is for by matching its attribute_value_ids
against the variant's, so an image with neither a template nor attribute
values belongs to nothing: product_template_image_ids does not contain it,
_compute_variant_image_ids never sees it, and the image is gone from the
shop while its row sits in the table.

Two shapes carry exactly, and are done separately because the faithful
answer differs:

the variant has attribute values -- the image was for that combination, so
it gets the template and those values, and stays specific to it

the variant has none and is the template's only one -- there is no
combination to be specific about, so the template alone says what 19.0
said

A variant with no attribute values on a template that has several is neither:
it is an obsolete combination, archived on the seed. Giving its image to the
template would put it on every variant, which is broader than 19.0 showed it,
so it is left alone and reported.

tests

A migration test pins the rules above against data constructed on 19.0 before the upgrade runs:

• openupgrade_scripts/scripts/website_sale/tests/data_website_sale_migration.py
• openupgrade_scripts/scripts/website_sale/tests/test_website_sale_migration.py

---

CI: red until #118 lands

The test job fails on duplicate key value violates unique constraint "res_country_state_name_code_uniq" (Ladakh / Odisha). Not this branch:
base's pre-migration, which renames those two external ids, lives in #118 and
is not on 20.0 yet, so every branch cut from 20.0 alone hits it. Per the
fork's model the per-PR check is the lean one; the real migration gate is the
integration branch (#120), where all of this runs green over the full
585-module seed.

AI-assisted (Claude Code); every change reviewed, tested, and owned by the author.