diff options
| author | jem-odoo <jem@openerp.com> | 2019-04-04 12:30:54 +0000 |
|---|---|---|
| committer | jem-odoo <jem@openerp.com> | 2019-04-08 07:58:01 +0000 |
| commit | 3be372cfc4e921c776a7aee391970966113fd39b (patch) | |
| tree | 529d2bf8b607da668f89ce8e653873a1bda958f5 /addons/web/static/src/js/views/basic | |
| parent | ea4a782f4908191fbe021f04d3a231cc6fee3d38 (diff) | |
[FIX] hr: restrict sudoing fields_view_get of res.users
Since d77ce4c2a92c1da48150e4e84b714dd93f64847d, the feature of editing own employee profile was
added. It was complicated with the access rights point of view because the
hr.employee fields are protected (groups="hr.group_hr_user"). To allow editing
its own hr.employee, it was required to `sudo` the field_view_get of res.users
(as the profile form view is a res.users form view, with related field from the
employee).
- Bug
The problem is that calling `fields_view_get` as `sudo` each time breaks the `groups`
mecanism on res.users views (not only form view). For instance, adding a field
on the form view with a group will always make it visible as the `groups`check
is done in sudo mode.
- Solution
This commit tries to fix this matter but reducing the `sudo` usage to
- only form view (we don't want this to applied to every res.users view type)
- only for internal user
- only in the flow of the "self editing profile", by checking the current action
- only for the current user (avoid to get the profile of other res.users by
using the same action)
- Side effect
The `groups` mecanism is still breaking on the "my profile" form view, as the
`sudo` is still applied in that case. We might tolerate this as the view should
only be accessible for the current user.
This is not perfect at all, but cleaning that properly might involve to redevelop
this sensitive feature.
Task-1916925
Diffstat (limited to 'addons/web/static/src/js/views/basic')
0 files changed, 0 insertions, 0 deletions
