[19.0][MIG] l10n_fr: cleanup obsolete res.partner.siret + orphan form view

[dnplkndll]

What

Add openupgrade_scripts/scripts/l10n_fr/19.0.2.1/:

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

The pre-migration deletes the stale ir_model_fields row for
res.partner.siret plus the orphan inheritance view
res_partner_form_l10n_fr. Both are marked DEL in the existing
upgrade_analysis.txt but were not actually pruned by Odoo's standard
upgrade flow.

Why

The 18.0 l10n_fr module added res.partner.siret (the French
SIRET tax identifier) plus a partner form inheritance view that exposed
it. In 19.0 both are removed from source. The directory previously
contained only the auto-generated upgrade_analysis.txt, so the
migration relied on Odoo's standard upgrade flow to drop the DEL field
and DEL view. That doesn't actually happen — the rows survive and the
view's arch_db retains <field name=\"siret\"/>, which causes
cross-cutting view validation to raise:

```
Field "siret" does not exist in model "res.partner"
```

when any later module's data XML load triggers the validation.
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 l10n_ae/data/account_tax_report_data.xml:3, after the
loyalty (#5629), hr (#5630), and partner_autocomplete
(#5631) companion fixes are applied.

How

cleanup_obsolete_l10n_fr_siret(env) lists the two 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 annotates the field DEL and
the view DEL blocks with # DONE comments cross-referencing the
helper, and marks the remaining XML-records entries as
# NOTHING TO DO (the standard upgrade handles them: NEW view is
auto-created, noupdate flip is standard, dom-tom group rename is in
apriori).

Test plan

• Reproduced on a fresh 18.0 CE-all install with the three
  companion fixes applied. Without this patch, migration crashes at
  module 217/608 (l10n_ae) on the siret field reference.
• With this patch: the migration progresses past the
  l10n_fr-related crash. (Any subsequent failure is a different
  module's analogous gap.)
• 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)
• [19.0][MIG] partner_autocomplete: cleanup obsolete res.partner/res.company fields #5631 (partner_autocomplete obsolete fields)
• [19.0][IMP] hr: backfill NULL create_date/write_date on hr_employee #5628 (hr null write_date backfill)

This fix continues the pattern surfaced by the comprehensive
CE-install benchmark: modules whose 19.0 upgrade_analysis.txt lists
DEL entries that Odoo's standard upgrade flow doesn't actually prune.

A separate small PR may be needed for l10n_fr_account which also
DEL's a partner-form view (res_partner_form_l10n_fr) on the same
analysis — that script directory similarly contains only the
auto-generated analysis file.

[pedrobaeza]

#5631 (comment)

[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.

[pedrobaeza]

You are welcome 😄