openerp-india team mailing list archive
-
openerp-india team
-
Mailing list archive
-
Message #11220
[Bug 996816] Re: using _inherit and _name for a class is not modular
class test_test_new(osv.osv):
_inherit = 'test.test'
_name = 'test.test.new'
_columns = {
'addnew': fields.char('New', size=64),
'partner' : fields.many2one('res.partner', 'Partner'),
}
test_test_new()
class test_test(osv.osv):
_inherit = 'test.test'
_name = 'test.test'
_columns = {
'user': fields.many2one('res.user','User'),
}
test_test()
So by suing this example if you check your print your table test_test_new then you didn't see the User field (which is the behaviour because test_test_new is loaded first then after we added a user field). If you change the seq of class like first main object then inherit main object and then load the test.test.new. You can see the User field (on test.test.new ).
*If we have update all object as you suggest then we have to check all
the object list which are already inherited then we have to add this new
field on all inherited object, I think which doesn't make sense. If I
inherit a one object 10 times and then for all this 10 object we have to
add new field.
That's I don't think we can consider this as a bug.
Please share your views
Thanks and waiting for your reply! Sorry for the inconvenience faced on comment!
** Changed in: openobject-server
Status: New => Incomplete
--
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:
Incomplete
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