Fixes #32213 - inform user about wrong use of admin flag
Our API filters the admin attribute of user group API via strong params for non-admin users. Therefore when non-admin tries to create or update a user group admin flag, it is silently ignored even and the user group correctly remains as is. Only admins can set this attribute.
From user perspective, this is not great. It's confusing why the explicitly set attribute is ignored. The user should be informed about the reason.
This patch removes the attribute filtering for the API and adds a model validation, which register the proper validation error which is then presented to the user.
The UI does not require any change since the flag is is not even displayed to the user. For security reason the flag continue to be filtered for the UI path. The validation in this case is another security level but in general should never be triggered through UI.
The API in this case returns 422 because the actual model is not valid. Technically this could also be 403 since user does not have enough permissions, but that would be confusing, since that status is for the case users don't have the edit_usergroups permission at all. 422 is more consistent with other cases, e.g. when user tries to set attribute to link the object he/she does not have view permission for.
Related issues
Bug #32213: changing "admin" parameter of user-group with non-admin user is accepted but nothing changed
Fixes #32213 - inform user about wrong use of admin flag
Our API filters the admin attribute of user group API via strong params
for non-admin users. Therefore when non-admin tries to create or update
a user group admin flag, it is silently ignored even and the user group
correctly remains as is. Only admins can set this attribute.
From user perspective, this is not great. It's confusing why the
explicitly set attribute is ignored. The user should be informed about
the reason.
This patch removes the attribute filtering for the API and adds a
model validation, which register the proper validation error which is
then presented to the user.
The UI does not require any change since the flag is is not even
displayed to the user. For security reason the flag continue to be
filtered for the UI path. The validation in this case is another
security level but in general should never be triggered through UI.
The API in this case returns 422 because the actual model is not valid.
Technically this could also be 403 since user does not have enough
permissions, but that would be confusing, since that status is for the
case users don't have the edit_usergroups permission at all. 422 is more
consistent with other cases, e.g. when user tries to set attribute to
link the object he/she does not have view permission for.