Jay, I understood perfectly how fields.related works, and that it works both with read and write as you explained. Now, I think you missed my point, I said that in the case the fields.related is declared as readonly=True (the example I gave), then the implementation of fields.related should not try to write the relation (as explained its sucks with access rights then). What do you think?
-- fields.related with readonly=True tries to write related object and can throw access rights errors https://bugs.launchpad.net/bugs/426676 You received this bug notification because you are a member of C2C OERPScenario, which is subscribed to the OpenERP Project Group. Status in OpenObject Server: Invalid Bug description: Hello this is a server bug, but we will use an extra addon module to show it here: 1) make sure to grap stable_5.0_extra-addons with revsion #3912 max (because I sent a temporary workaround after that revision in order that my customer, Anevia, which has a maintenance contract with Tiny, avoid access rights troubles. 1) install a fresh database with manufacturing profile and demo data 2) install the fleet_maintenance module from stable_5.0_extra-addons, so with rev #3912 max 3) change demo user to add the Sale/Salesman group to him (along with employee) 4) alter PC1 demo product to check the 'is_maintenance' checkbox 5) in menu Fleets>Fleets, create a new fleet "f1" for the Axelor partner 6) in menu Fleets>Fleet Extensions create a new fleet extension "ext1" with the previous "f1" fleet as the parent location 7) make a new sale order for partner Axelor with "default fleet" field set to "ext1" add the 1 PC1 product in the first sale order line save the sale order as it is 8) try to duplicate the sale order using Form > Duplicate in the GTK menu. You will get an access right violation exception because the Sales/Salesman group has no write right on the product.product object. Still, this is a misbehavior of the Openobject server because the in the inherited sale_order_line object the is_maintenance field is defined as readonly=Tue so OpenObject could avoid trying to write the product.product object at record duplication. The exact stack trace you get by using the --debug option is: Environment Information : System : Linux-2.6.28-15-generic-x86_64-with-Ubuntu-9.04-jaunty OS Name : posix Distributor ID: Ubuntu Description: Ubuntu 9.04 Release: 9.04 Codename: jaunty Operating System Release : 2.6.28-15-generic Operating System Version : #49-Ubuntu SMP Tue Aug 18 19:25:34 UTC 2009 Operating System Architecture : 64bit Operating System Locale : en_US.UTF8 Python Version : 2.6.2 OpenERP-Client Version : 5.0.5-bzr Last revision No. & ID : 988 [email protected] Traceback (most recent call last): File "/home/rvalyi/DEV/openerp5.0/server/bin/netsvc.py", line 244, in dispatch result = LocalService(service_name)(method, *params) File "/home/rvalyi/DEV/openerp5.0/server/bin/netsvc.py", line 73, in __call__ return getattr(self, method)(*params) File "/home/rvalyi/DEV/openerp5.0/server/bin/service/web_services.py", line 583, in execute res = service.execute(db, uid, object, method, *args) File "/home/rvalyi/DEV/openerp5.0/server/bin/osv/osv.py", line 61, in wrapper self.abortResponse(1, inst.name, 'warning', inst.value) File "/home/rvalyi/DEV/openerp5.0/server/bin/osv/osv.py", line 59, in wrapper return f(self, dbname, *args, **kwargs) File "/home/rvalyi/DEV/openerp5.0/server/bin/osv/osv.py", line 118, in execute res = pool.execute_cr(cr, uid, obj, method, *args, **kw) File "/home/rvalyi/DEV/openerp5.0/server/bin/osv/osv.py", line 110, in execute_cr return getattr(object, method)(cr, uid, *args, **kw) File "/home/rvalyi/DEV/openerp5.0/addons/sale/sale.py", line 64, in copy return super(sale_order, self).copy(cr, uid, id, default, context) File "/home/rvalyi/DEV/openerp5.0/server/bin/osv/orm.py", line 2952, in copy new_id = self.create(cr, uid, data, context) File "/home/rvalyi/DEV/openerp5.0/addons/sale/sale.py", line 346, in create return super(sale_order, self).create(cr, uid, vals, context=context) File "/home/rvalyi/DEV/openerp5.0/server/bin/osv/orm.py", line 2682, in create result += self._columns[field].set(cr, self, id_new, field, vals[field], user, rel_context) or [] File "/home/rvalyi/DEV/openerp5.0/server/bin/osv/fields.py", line 446, in set id_new = obj.create(cr, user, act[2], context=context) File "/home/rvalyi/DEV/openerp5.0/server/bin/osv/orm.py", line 2682, in create result += self._columns[field].set(cr, self, id_new, field, vals[field], user, rel_context) or [] File "/home/rvalyi/DEV/openerp5.0/server/bin/osv/fields.py", line 665, in set self._fnct_inv(obj, cr, user, id, name, value, self._fnct_inv_arg, context) File "/home/rvalyi/DEV/openerp5.0/server/bin/osv/fields.py", line 716, in _fnct_write obj.pool.get(field_detail['object']).write(cr,uid,[t_id],{args[-1]:values}) File "/home/rvalyi/DEV/openerp5.0/server/bin/osv/orm.py", line 2383, in write self.pool.get('ir.model.access').check(cr, user, self._name, 'write', context=context) File "/home/rvalyi/DEV/openerp5.0/server/bin/tools/misc.py", line 686, in cached_result result2 = fn(self2, cr, *args[:self.skiparg-2], **kwargs2) File "/home/rvalyi/DEV/openerp5.0/server/bin/addons/base/ir/ir_model.py", line 362, in check raise except_orm(_('AccessError'), msgs[mode] % model_name ) except_orm: ('AccessError', 'You can not write in this document! (product.product)') Hope this helps. A workaround for me has been to override the create method of the sale_order_line object removing the is_maintenance field, see subsequent commits. Still we shouldn't have to pollute the code that way I think as we already declared the readonly nature of the is_maintenance related field. _______________________________________________ Mailing list: https://launchpad.net/~c2c-oerpscenario Post to : [email protected] Unsubscribe : https://launchpad.net/~c2c-oerpscenario More help : https://help.launchpad.net/ListHelp
