openerp-india team mailing list archive
-
openerp-india team
-
Mailing list archive
-
Message #11383
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