[19.0][MIG] partner_autocomplete: cleanup obsolete res.partner/res.company fields

[dnplkndll]

What

Add openupgrade_scripts/scripts/partner_autocomplete/19.0.1.1/:

• pre-migration.py with cleanup_obsolete_partner_autocomplete_records(env)
• upgrade_analysis_work.txt annotating the analysis blocks

The pre-migration deletes the stale ir_model_fields rows + orphan
inheritance ir_ui_view records for three fields and two views the 18.0
partner_autocomplete module added that the 19.0 source no longer
defines (per upgrade_analysis.txt):

• res.company.partner_gid
• res.partner.additional_info
• res.partner.partner_gid
• view view_partner_simple_form_inherit_partner_autocomplete
• view view_res_partner_form_inherit_partner_autocomplete

Why

The directory previously contained only the auto-generated
upgrade_analysis.txt. The migration relied on Odoo's standard upgrade
flow to clean up DEL fields and DEL views. That holds for some module
upgrades but not all — in this case the stale ir_model_fields rows
plus the matching views (whose arch_db retains
<field name=\"partner_gid\"/> etc.) survive the upgrade. When any
later module's data XML load triggers cross-cutting view validation,
the orphan view tries to render and Odoo raises:

```
Field 'partner_gid' does not exist in model 'res.partner'
Field 'additional_info' does not exist in model 'res.partner'
```

which aborts the migration. Reproduced on a fresh 18.0 → 19.0 install
(odoo -i all then -u all): the crash hits at module 217/608
l10n_ae while parsing account_tax_report_data.xml:3.

How

cleanup_obsolete_partner_autocomplete_records(env) lists the five
known-obsolete xml_ids and passes them to
openupgrade.delete_records_safely_by_xml_id. That deletes the
ir_model_data backrefs + the underlying ir_model_fields /
ir_ui_view records together, falling back to noupdate=True if a
record can't be removed (per the helper's existing behaviour).

The companion upgrade_analysis_work.txt carries the standard
section structure with one # DONE block above each DEL group, plus a
# NOTHING TO DO for the obsolete-model entries (the standard
module-removal flow drops those tables) and the DEL access-rights /
cron entries (those are deleted by the standard upgrade).

Test plan

• Reproduced on a fresh 18.0 CE-all install with the loyalty fix
  ([19.0][FIX] loyalty: clear stale mail.template.lang referencing removed _get_mail_partner #5629) and the hr cleanup fix
  ([19.0][FIX] hr: cleanup obsolete hr.employee fields from merged hr_contract #5630) applied. Without this patch, migration
  crashes at module 217/608 (l10n_ae).
• With this patch (and the two companions), the migration progresses
  past the partner_autocomplete-related crash. Continued failures
  surface separately (e.g. siret on res.partner from
  l10n_fr — that's a future PR).
• OCA CI green.

Related

• [19.0][FIX] loyalty: clear stale mail.template.lang referencing removed _get_mail_partner #5629 (loyalty mail.template.lang)
• [19.0][FIX] hr: cleanup obsolete hr.employee fields from merged hr_contract #5630 (hr obsolete hr_contract field cleanup)

This fix is one of a small series surfacing the same class of issue:
modules with DEL field/view entries in their 19.0 analysis whose
standard upgrade flow does not actually prune the stale records.

[pedrobaeza]

Please don't do this. We don't explicitly clean things, unless there's a conflict not doing so.

Why? First, because one of the aims of OpenUpgrade is to preserve at maximum the previous information, as that can be used by other migration scripts for doing their work, or simply to recover from disasters.

Secondly, there are other tools that do that cleanup if needed. In the case of the views, they are naturally removed on the next real update (-u all) that is done, which should be performed right after the migration itself. What you are doing is even worse, as using delete_records_safely_by_xml_id will silently remove the XML-ID, but keep the view if there are children views, which is very likely. For the fields, columns and tables, we have the module database_cleanup for doing such cleanup, but I always delay its execution until I'm pretty sure the new version is correctly in usage for several weeks.

Please do the strict migration scripts.

[pedrobaeza]

See previous explanation

[dnplkndll]

Closing per maintainer guidance in #5631 (comment).

Understood: OpenUpgrade aims to preserve previous information, the natural -u all after migration sweeps orphan views, and database_cleanup is the right place for residual field/column/table tidy-up (delayed until the new version is in use).

For the specific failure mode that motivated these PRs (cross-cutting view validation triggered by l10n_ae/data/account_tax_report_data.xml:3 during -u all raising Field X does not exist on res.partner / hr.employee etc.), I'll continue investigating outside this PR and may open separate issues with concrete reproductions if I can isolate the trigger to upstream Odoo or to a specific OpenUpgrade gap that needs strict (rather than cleanup-style) handling.

Thanks for the clear philosophical guidance — saved me from writing another 100+ similar PRs.