-
- Downloads
[FIX] base: fix portal rights update
Commit c3717f30 added a (5, 0, 0) command when modifying groups_id of any non-internal user, to avoid the situation where the various implications would end up giving the portal user group_user rights. This risk is avoided by commit f206714a, which added a constraint check_one_user_type, which would raise in that specific case. The last missing piece was 9badedcd; when groups are added through settings, they are added through the implied_groups of the group model. The (5,) command has the unfortunate side-effect to remove the portal group from a user if a write is triggered programmatically. If that happens, then the 'signing up' process end-destination is a 500 error. Now we simplify the logic that keeping the same behaviour for implied_ids for internal (group_user) and non-internal users. We keep the (5,) command in one case: if a user is demoted to portal or public, he may have groups should be reserved to internal users, but that do not imply group_user (which would raise). To avoid that, we remove all its groups, since there is no clear distinction between technical display groups and actual privilege-granting groups. opw 2041606 closes odoo/odoo#35347 Signed-off-by:Nans Lefebvre (len) <len@odoo.com>
Showing
- odoo/addons/base/models/res_users.py 5 additions, 9 deletionsodoo/addons/base/models/res_users.py
- odoo/addons/base/tests/__init__.py 0 additions, 1 deletionodoo/addons/base/tests/__init__.py
- odoo/addons/base/tests/test_non_regression.py 0 additions, 32 deletionsodoo/addons/base/tests/test_non_regression.py
- odoo/addons/base/tests/test_user_has_group.py 115 additions, 27 deletionsodoo/addons/base/tests/test_user_has_group.py
Please register or sign in to comment