[FIX] base: fix portal user creation in debug mode

It is possible 29723e351d5 through the interface, in debug mode,
to create a portal or a public user.
Because of 29723e351d5, doing so raise: the user that it tries to create also
has internal user rights, which is forbidden for obvious security reasons.

The goal of 29723e351d5 was to restore normal behaviour when changing rights of
a non-internal user, i.e. to respect the groups given in arguments and their
implications. Most user creations happen programmatically, e.g. when a user
signs up on the website, so without that commit it was not possible to set up
the groups correctly in case of modifications, etc, since both create and write
did not use the provided group arguments.

However when passing through the interface, for portal or public users all the
other groups are hidden, but their values are not removed. Since these groups
confer user privileges, they imply internal user rights, which is forbidden for
a portal user, and raises.
Note that before a user created this way could not have the exact same rights
a portal user should have had, since technical groups should have been added
through the implied ids.
For this reason as well the fact that groups can be badly manipulated manually,
it is discouraged to use debug mode to to these actions, but still possible.

Since both flows simply use create, we fix the data that is sent by
the interface.
We cannot use an onchange to clean the groups since we are in the reified view.
So to avoid the JS sending the commands, we need to put the fields in readonly
if they are invisible.
To do so we also need to process the "user type" groups first.
Note that the sorting is stable, so the order is identical as before.

closes odoo/odoo#37839

X-original-commit: 3c44a5afe83465a76d16356e0fd6336b4d9c9196
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>

0 files changed, 0 insertions, 0 deletions