跳至内容
菜单
此问题已终结
1 回复
128 查看

We have 2 custom modules A and B:

Module A extends res.partner by a simple selection from a static list of predefined values:

class Partner(models.Model):
_inherit = "res.partner"
status = fields.Selection(STATUS, default="0")

Module B (depending on A by its manifest) extends account.move and relates to the status of a company via a Many2One:

class AccountMove(models.Model):
_inherit = "account.move"
partner_company_id = fields.Many2one("res.partner", compute="_compute_parent", store=True)
status = fields.Selection(related="partner_company_id.status", store=True)

After later changes to module A we want to upgrade it in Odoo via the 'Apps' menu, but we get an error message (the same we get when we try to upgrade module B with no changes at all).

File "/odoo17/odoo/fields.py", line 606, in setup_related
    raise KeyError(
KeyError: 'Field status referenced in related field definition account.move.status does not exist.'

Can we fix this somehow? Or is this an Odoo bug, due to the Many2One->related combination that Odoo can not handle correctly on the upgrade / transition?

形象
丢弃
最佳答案

Hi,



This issue occurs because of how Odoo handles module dependencies and related fields during upgrades. In your setup, Module A adds the status field to res.partner, while Module B creates a related field in account.move that depends on res.partner.status. When you upgrade Module A, Odoo temporarily reloads its model definitions, and since Module B’s related field still references a field that hasn’t been fully reloaded, it triggers a KeyError. This isn’t exactly a bug in your code but rather a limitation of Odoo’s registry initialization process when dealing with interdependent modules.


To fix it, the simplest method is to upgrade the modules in the correct order, upgrade Module A first, then Module B. If the Apps interface doesn’t work, this can be done using terminal commands with -u module_a followed by -u module_b.


If that doesn’t resolve it, you can temporarily disable the related field in Module B (by removing the related parameter), upgrade Module A, and then restore the related field after Module A has loaded successfully.


A more robust solution is to replace the related field with a computed field that depends on partner_company_id.status. This avoids hard registry dependencies during startup and ensures that upgrades run smoothly regardless of the module loading order.


Finally, make sure Module B’s manifest explicitly declares a dependency on Module A. In short, this issue is caused by Odoo’s dependency loading sequence, and the best long-term fix is to use a computed field or carefully manage module upgrade order.


Hope it helps

形象
丢弃
相关帖文 回复 查看 活动
1
1月 24
2784
1
1月 24
1879
0
5月 15
7026
1
7月 24
3779
0
5月 24
1618