[dnplkndll]

post-migration.py

hs_code and country_of_origin move from product.template to product.product.

19.0 stored both on product.template. 20.0 stores them on product.product
and leaves the template a computed, non-stored view of its single variant,
with an inverse that writes back. So the direction reverses, and the
template column stops being read at all.

OpenUpgrade keeps that column, which is what makes this quiet: nothing
raises, no constraint is missed, and every product simply comes out of the
upgrade with no HS code and no origin. On a customs-declaring database that
is the whole of the data.

Every variant of a template takes the template's value, because in 19.0 the
value applied to the template as a whole. 20.0's own compute only surfaces a
variant value back onto the template when there is exactly one variant,
which is a display rule rather than a reason to migrate fewer rows.

Nothing to assert on the seed: both columns are empty there in 19.0 and in
20.0 alike, so this is one the dataset cannot discriminate -- the evidence
is the pair of field definitions, not a row count.

---

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.