openerp-india team mailing list archive

["Olivier Dony \(OpenERP\)" <996816@xxxxxxxxxxxxxxxxxx>]

I agree with Quentin, this is an annoying issue affecting the flexibility and consistency of OpenERP when inheriting by prototype (using _inherit with a different _name).
As we've seen there are many bugs that come from this: all those bugs with missing columns and SQL errors that depend on the order of module installation.

We want OpenERP module installation to work regardless of the order in
which unrelated modules are installed, and due to this issue we do not
have the guarantee that it will work at the moment.

Amit, we have fixed some of the current bug reports on addons side, but
in every case it was a dirty hack, usually by copying the column from
the parent, or introducing "fake" dependencies. This is not good at all,
and proves we need to find a solution at the framework level.

One possible technical solution would be for the system to refresh all "cousin" (different _name) models when a new _inheriting model is loaded, but I think that requires quite a lot of low-level hacking in the module loading code. In order to refresh/reload a given "cousin" model we'd have to go though its inheritance tree, and refresh all ancestors, possibly requiring the original Python class to be available in the process. And this would have to be done during module install/upgrade as well, in order to properly update the database schema.
So I'm not quite sure of the technical solution to adopt, but we definitely need to solve this.

** Changed in: openobject-server
       Status: Triaged => Confirmed

-- 
You received this bug notification because you are a member of OpenERP
Indian Team, which is subscribed to OpenERP Server.
https://bugs.launchpad.net/bugs/996816

Title:
  using _inherit and _name for a class is not modular

Status in OpenERP Server:
  Confirmed

Bug description:
  If you define a class that use _inherit and _name, to make a copy of
  the parent class, you expect that any modification made by a tier
  module is applied to both the parent and the copy classes. But it's
  not the case and here are the steps to help you to figure it out:

  1°) My aim is to use a copy of the stock.picking class for incoming shipments, it will allow me to simplify the code a lot (especially in the views definition). So i defined a class stock.picking.in as follow (stock/stock.py):
  class stock_picking_in(osv.osv):
      _inherit= 'stock.picking'
      _name='stock.picking.in'
      _table='stock_picking'    #(here the copy model is using the same table as the parent, but it's not relevant for the bug description, and the same apply if the table is different)
      ...

  2°) in purchase module, i changed the one2many field on the purchase order that referred to the stock_picking table. What i need to do is to reference the class stock.picking.in, instead of the stock.picking.  So i defined it as follow (purchase/purchase.py, line 176): 
         'picking_ids': fields.one2many('stock.picking.in', 'purchase_id', 'Picking List', readonly=True, help="This is the list of incoming shipments that have been generated for this purchase order."),

  3°) the purchase module already include some code to add the field purchase_id on the stock.picking class and table (purchase/stock.py):
   37 class stock_picking(osv.osv):
   38     _inherit = 'stock.picking'
   39     _columns = {
   40         'purchase_id': fields.many2one('purchase.order', 'Purchase Order',
   41             ondelete='set null', select=True),
   42     }

  So i thought it would be ok like this... But, no it isn't. At the
  purchase module installation a traceback is telling me that the field
  purchase_id doesn't exists on the stock.picking.in model. The addition
  of it on stock.picking didn't propagate to my class.

  This is really problematic because it means that using _inherit and
  _name on the same class is not modular.

  *Note that, in the meanwhile this bug is solved (if it will be) i this used a workaround: i just copied the add of the purchase_id field on my new stock.picking.in class too, in this way (purchase/stock.py):
  129 # Redefinition of the new field in order to update the model stock.picking.in in the orm
  132 class stock_picking_in(osv.osv):
  133     _inherit = 'stock.picking.in'
  134     _columns = {
  135         'purchase_id': fields.many2one('purchase.order', 'Purchase Order',
  136             ondelete='set null', select=True),
  137     }
  So yeah, it works but it's not convenient. If we want to use more and more this feature we should improve its modularity. Please be kind and remove this hack[*] whenever the framework support this feature.

  Thanks, 
  Quentin

  
  [*]: the same applies for the sale module, of course. Lines to remove when it's fixed are in sale/stock.py
  189 # Redefinition of the new field in order to update the model stock.picking.out in the orm
  192 class stock_picking_out(osv.osv):
  193     _inherit = 'stock.picking.out'
  194     _columns = {
  195         'sale_id': fields.many2one('sale.order', 'Sale Order',
  196             ondelete='set null', select=True),
  197     }

To manage notifications about this bug go to:
https://bugs.launchpad.net/openobject-server/+bug/996816/+subscriptions