[FIX] util/models: Prevent removal manual relation table

[sagu-odoo]

There are two model A and B and there is
x many2many field in A model which is manual and relation with B. Now, B model is removed. So, For that relation table is droped but the field will there and in relation model _unknown will be set

upgrade-util/src/util/models.py

Line 242 in 25cb373

cr.execute("UPDATE ir_model_fields SET relation = '_unknown' WHERE relation = %s", [model])

.

As the field belongs to A. So, table will be recreated from here as it checks only table is there or not and after that from here env variable it have in gone and below menitoned traceback will raise. To Fix, Preventing table for manual fields. So, field can be checked later on and to prevent blocking.

Traceback (most recent call last):
  File "/home/odoo/src/odoo/19.0/odoo/service/server.py", line 1509, in preload_registries
    registry = Registry.new(dbname, update_module=update_module, install_modules=config['init'], upgrade_modules=config['update'], reinit_modules=config['reinit'])
  File "/home/odoo/src/odoo/19.0/odoo/tools/func.py", line 88, in locked
    return func(inst, *args, **kwargs)
  File "/home/odoo/src/odoo/19.0/odoo/orm/registry.py", line 185, in new
    load_modules(
  File "/home/odoo/src/odoo/19.0/odoo/modules/loading.py", line 580, in load_modules
    model._register_hook()
  File "/tmp/tmpkw62chtg/migrations/base/0.0.0/pre-models-ir_model_relation.py", line 49, in _register_hook
    raise util.MigrationError("The following m2m relations have respawn:\n%s" % back_m2m)
odoo.upgrade.util.exceptions.UpgradeError: The following m2m relations have respawn:
 - x_res_partner_uom_category_rel via uom.category

upg-3191893
opw-5175564

[robodoo]

[sagu-odoo]

Hello @odoo/upgrade , could you please review the pr ?.

Thanks in advance

[jjmaksoud]

Those manual fields related to removed models need to be addressed by db users, as the information they hold will be lost (with or without this PR). They should be either removed or changed, and letting the upgrade pass while dropping all their data can cause their drop to be unnoticed.

[sagu-odoo]

Thanks for the review. I found that there is a TBG for this (link). Since we are removing the table, the related fields should also be removed and should be added into migration report. This will ensure the upgrade does not get blocked, and if any of those fields are still used somewhere in a view, we can fix it at that time. This way, the user can at least proceed to test the other flows.

[sagu-odoo]

Hello @jjmaksoud , could you please have a look a another look ?.

Thanks

[jjmaksoud]

the related fields should also be removed and should be added into migration report

Yes this would be a better alternative for manual m2ms

[sagu-odoo]

I have made the changes. could you Please have a look ?.

[sagu-odoo]

upgradeci retry with base

[jjmaksoud]

upgradeci retry with always only base

[sagu-odoo]

could you please have a another look?. If still anything left do let me know :(