c2c-oerpscenario team mailing list archive

["Jay \(OpenERP\)" <jvo@xxxxxxxxxxx>]

Raphaël,

Thanks for coming back on this.

I agree to your point of readonly field.

I will install the module, setup the scenario and face the problem and
share my word.

Thanks.

-- 
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 christophe@xxxxxxxxxxx-20090828170245-gjtf2ca7vczbefpr
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.