This PR fixes unexpected behavior when invoking the group API.
Similar to the work done in #295 .
Changes
CreateGroup now adds the explicit entitlement can_view to user:{userID} since it would not work otherwise
GetGroupDetail now returns
the group id in case it's present and the user is allowed to view it
404 in case the group is not present and the user is allowed to view
403 in case the user is not allowed to view it (no matter if the role is present or not, this info is concealed from the unauthorized user)
DeleteRole now removes also all direct associations from the group, meaning all can_view, can_edit, can_delete, can_create, member, privileged are removed when the group is removed
tests are adjusted
NB: a subsequent PR will take care of returning errors from the concurrent deletions, this requires more work on the worker pool side and on the role service, so it needs to be done separately. This is way the remove role test is not testing error for now.
Description
This PR fixes unexpected behavior when invoking the group API.
Similar to the work done in #295 .
Changes
can_viewto user:{userID} since it would not work otherwisecan_view,can_edit,can_delete,can_create,member,privilegedare removed when the group is removedNB: a subsequent PR will take care of returning errors from the concurrent deletions, this requires more work on the worker pool side and on the role service, so it needs to be done separately. This is way the remove role test is not testing error for now.