On 25/05/2012 09:28, Olivier Dony wrote: > On 05/22/2012 01:35 PM, Alexandre Fayolle wrote: >> I'm coding a module which is similar in purpose to product_margin but >> works with a very different flow, which makes it meaningless to have >> both modules installed at the same time on a given instance. Is there a >> way of forbidding the installation of one of the two modules if the >> other one is already there, such as the Conflicts: field in a Debian >> package? This would mean that I'm able to use some of the nicely named >> columns from product_margin in my module. > There is no exclusion mechanism foreseen in the API yet, because it's usually > better to make the modules properly orthogonal and compatible with each other, > or explicitly dependent of each other. > For example if your module kind of supersedes product_margin, you could make > it > depend on it and reuse whatever columns you like, while > hiding/disabling/overriding the rest of the module. That makes perfect sense > in > terms of modularity and dependencies. >
Having such dependency information would enable avoiding problems such as https://bugs.launchpad.net/bugs/808683 (sale_margin and sale_layout are not compatible) by preventing the simultaneous installation of both modules (whether the incompatibility itself is a bug or not is another debate). I understand that the best way is to have orthogonal modules. It's just that we can't always achieve this. I seems conceivable to have two different and incompatible ways of performing a given business task. So I'm in favor of any plan pushing towards that direction. Thanks -- Alexandre Fayolle Chef de Projet Tel : + 33 (0)4 79 26 57 92 Camptocamp France SAS Savoie Technolac, BP 352 73377 Le Bourget du Lac Cedex http://www.camptocamp.com _______________________________________________ Mailing list: https://launchpad.net/~openerp-expert-framework Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-expert-framework More help : https://help.launchpad.net/ListHelp
