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
Community Backports Team, which is subscribed to OpenERP Community
Backports (Addons).
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

-- 
Mailing list: https://launchpad.net/~openerp-community-reviewer
Post to     : openerp-community-reviewer@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openerp-community-reviewer
More help   : https://help.launchpad.net/ListHelp

Reply via email to