[FIX] base: access to preferences menu for portal users
Since revs53582c2ea6
&f65c913027
, this was no more possible for portal users to read groups on purpose, for privacy reasons. fields_get of res.users model is overriden, for the access rights form view features (The groups selections and checkboxes). At each call to fields_get, which happens at each call to fields_view_get on the res.users model, operations are done on the model res.groups (basically, to build the selection groups and checkboxes). So, each time a view of model res.users is displayed, whatever the view, operations on res.group model were performed. The thing is, these operations on res.groups are actually needed only for the user access rights view, or at least only for users having the group Administration > Access rights. These group operations aren't needed for the preferences view, nor for portal users. We therefore avoid to do these if the user is not part of the Administration > Access rights group, which lead to performances improvment, and solves the fact portal users couldn't access their user preferences view. opw-627391
This commit is contained in:
parent
a36396b192
commit
a93ef48a70
|
@ -860,6 +860,8 @@ class users_view(osv.osv):
|
|||
def fields_get(self, cr, uid, allfields=None, context=None, write_access=True):
|
||||
res = super(users_view, self).fields_get(cr, uid, allfields, context, write_access)
|
||||
# add reified groups fields
|
||||
if uid != SUPERUSER_ID and not self.pool['res.users'].has_group(cr, uid, 'base.group_erp_manager'):
|
||||
return res
|
||||
for app, kind, gs in self.pool.get('res.groups').get_groups_by_application(cr, uid, context):
|
||||
if kind == 'selection':
|
||||
# selection group field
|
||||
|
|
Loading…
Reference in New Issue