[dnplkndll]

post-migration.py

Point existing points of sale at the default product 20.0 ships.

pos.config.default_product_id is new in 20.0 and defaults to
pos_sale.default_sol_product, a product the module itself loads. A default
only runs for rows created after it exists, so every point of sale that
predates the upgrade comes out with none and cannot price a productless
sale order line -- while one created a minute later can.

This is the case the OCA retrospective records us getting wrong last cycle:
a default is not automatically safe, and the question is what it means on a
row that already existed. Here it means the same as on a new one, so the
rows are brought into line with what a fresh install would have.

Only the empty ones: a point of sale that already names a product chose it.

---

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.