[dnplkndll]

Port of openupgrade_framework from 19.0 to 20.0. Fork-only review PR — OCA has
no 20.0 branch yet, so the base here is 19.0 and a [DO NOT MERGE] commit
carries the series pin. Drop that commit when re-basing onto the real branch.

This is the gate for everything else: without it a 19→20 run dies on the first
stale inherited view, long before any upgrade script gets a chance to run.

Why the diff is so small

Every patch under odoo_patch/ wraps its target through _original_method and
forwards *args/**kwargs, rather than copying the core body. So the substantial
20.0 rewrites of BaseModel.unlink and load_module_graph need no adaptation,
and load_module_graph dropping its models_to_check parameter is absorbed by
the forwarding. I checked every patch target and helper resolves on 20.0 —
MODULE_UNINSTALL_FLAG, models.MAGIC_COLUMNS, registry._force_upgrade_scripts,
get_resource_from_path, and all eleven patched methods.

The one real removal

The ModuleGraph._update_from_database patch carried an 18→19 fixup:

# v19-specific: ir.model.fields#translate has changed semantics ...
self._cr.execute("UPDATE ir_model_fields SET translate=NULL where translate::varchar='false'")

It normalised translate='false' to NULL while that column was mid-conversion
from boolean to varchar. On a 19.0 source the column is already varchar holding
NULL / standard / html_translate / xml_translate, and the translate selection
is byte-identical in 20.0 — so the statement matches zero rows and no longer
describes a real step. Removed rather than left as a no-op.

Verification

Ran against a 19.0 database (154 core modules, 1100 ACLs, 311 record rules) with
a local arm64 build of odoo/odoo 20.0 at 310a97e0:

--load=base,web,openupgrade_framework -u all

Before this port the run aborts:

ParseError: while parsing base/views/res_partner_views.xml:317
Element '<filter name="type_company">' cannot be located in parent view
  xmlid: hr_calendar.view_res_partner_filter_inherit_calendar

With it, that becomes a logged warning from
openupgrade_framework.odoo_patch.odoo.addons.base.models.ir_ui_view
("Can't render custom view … Assuming you are migrating between major versions")
and the load continues — which is the patch doing exactly its job.

The run then stops further on, at base/security/ir.access.csv, for a reason
that is not a framework problem and is the next piece of work:

For external id base.access_decimal_precision_config when trying to create/update
a record of model ir.access found record of different model ir.model.access (6478)

20.0 reuses the 19.0 ACL external ids for the new ir.access model, so every
ir_model_data row still pointing at ir.model.access (and ir.rule) has to be
converted and re-pointed. That belongs in a base pre-migration script in
openupgrade_scripts, not here.

All of this ran on an internal-only Docker network with egress verified absent.

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

---

CI: the migration job fails on this branch, by construction

Test OpenUpgrade migration is red here and green on
#120. That is the expected
shape, not a defect in this port.

The coverage table on the 20.0 series branch marks base as the one module
CI migrates, so every PR branch is asked to migrate it. This branch carries
only the framework; the base migration script lives in
#118. Without it the run
stops where it always did before that script existed — the
res_country_state insert, because nothing has renamed
base.state_in_or to base.state_in_od yet:

ERROR odoo.sql_db: bad query: b'INSERT INTO "res_country_state" ...

A slice of the work cannot pass an integration test. #120 stacks framework +
base scripts + analysis + the per-module scripts and is the gate that means
something: it migrates 564 modules end to end, Modules loaded, Registry loaded in 1767s.