← Back to team overview

openerp-india team mailing list archive

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

 

Hi,

About 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.

I think, (not sure) you should add a new class in a new module depends on
you new module named stock_ext which contains the stock.picking.in and
stock.picking.out definition.
or you add a new class in the module stock_ext directly.
in new class, you should inherit purchase_order and redefine the
picking_ids field.
and as the same, you should redefine the picking_ids field of sale_order.

You can try it.

Andy

2012/5/12 Amit Parik (OpenERP) <amp@xxxxxxxxxxx>

> After the Experts suggestion and discussion we will set appropriate
> "Status" of this bug.
>
> Thanks!
>
> --
> 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:
>  Triaged
>
> 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-expert-framework
> Post to     : openerp-expert-framework@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openerp-expert-framework
> More help   : https://help.launchpad.net/ListHelp
>

-- 
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:
  Triaged

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


References