This question has been flagged
2 Replies
7702 Views

Sometimes, you have 2 modules acting on the same view but which can act interdependently.

And when one of those modules start to redefine completely the view or mode commonly delete an element of the view, there are some trouble in compatibility.

However, in most case you could find a way to install both without issue.

But then you push the dangerous update button of one module and not the other or try a base update, and there everything is stuck because of some issue like, the module B cannot find the attribute of the field X because module A removed it. But if you had installed the module A before the module B it would work.

How can we settle this kind of issue to make more compatibility between modules?

Is there a way to make sure a view of a module is loaded before the other? Moreover is there a way to check if an other module is installed and if so do some different behaviors?

Setting in __openerp__.py a module as a dependency is not a solution as it would force its install and we don't want that to happen.

Avatar
Discard
Best Answer

View priority (sequence) defines the order of application during view inheritance:

View matching

  • if a view is requested by (model, type), the view with the right model and type, mode=primary and the lowest priority is matched

  • when a view is requested by id, if its mode is not primary its closest parent with mode primary is matched

View resolution

Resolution generates the final arch for a requested/matched primary view:

  1. if the view has a parent, the parent is fully resolved then the current view's inheritance specs are applied

  2. if the view has no parent, its arch is used as-is

  3. the current view's children with mode extension are looked up and their inheritance specs are applied depth-first (a child view is applied, then its children, then its siblings)

The result of applying children views yields the final arch

https://www.odoo.com/documentation/10.0/reference/views.html#reference-views-inheritance

Avatar
Discard
Best Answer

I would be interested as to what folks think about this patch to 9.0 openerp/modules/graph.py def add_modules, right before the line that starts "dependencies =".

The idea is that you add always_extends = ['module1', 'module2'] to the __openerp__.py of a 'new_module'.  Every other module that depends on module1 or module2 will also be treated as being dependent on new_module, which forces new_module to load before any other dependencies of module1 or module2.

I have found this useful especially when I am trying to insert a module in between existing ones.

Thoughts?  Did I do a good thing here?

Jim

        # 13.0.4.0.12-t13 jrook begin adding always_extends

raw_packages = packages
packages = []
extend_depends = {}

for p, info in raw_packages:
extend_depends[p] = []

for p, info in raw_packages:
always_extends = info.get('always_extends') or []
for extend in always_extends:
if extend in info['depends']:
for p2, info2 in raw_packages:
if p2 != p and extend in info2['depends']: # if another module depends on this always_extend
extend_depends[p2].append(p) # then treat other module as depending on this module also

for p, info in raw_packages:
info['depends'] = info['depends'] + extend_depends[p]
packages.append((p, info))

# 13.0.4.0.12-t13 jrook done adding always_extends

That's it.  Add to your graph.py, and use 'always_depends' in your __openerp__.py's.

Avatar
Discard