← Back to team overview

openerp-expert-framework team mailing list archive

[Bug 996816] Re: using _inherit and _name for a class is not modular

 

Removing from ocb-addons as there is no merge proposal.


** No longer affects: ocb-addons

** No longer affects: ocb-addons/7.0

-- 
You received this bug notification because you are a member of OpenERP
Framework Experts, which is subscribed to the bug report.
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