Skip to content

Conversation

@sagu-odoo
Copy link
Contributor

@sagu-odoo sagu-odoo commented Nov 3, 2025

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

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

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
https://github.com/odoo/upgrade-util/blob/25cb37389b527f442acfbb704e07769d69b11b9f/src/util/models.py#L242.

As the field belongs to ``A``. So, table will be recreated
from here as it checks only table is there or not
https://github.com/odoo/odoo/blob/54f10b56f577ad9ed5575bd396dba7d20d22fc2e/odoo/fields.py#L4977
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
Copy link
Contributor

robodoo commented Nov 3, 2025

Pull request status dashboard

@sagu-odoo sagu-odoo requested review from a team and jjmaksoud November 4, 2025 08:58
@sagu-odoo
Copy link
Contributor Author

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

Thanks in advance

Copy link
Contributor

@jjmaksoud jjmaksoud left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Contributor Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants