An user cannot view groups he is a member of via self-service > my groups

[Dush]

Hi 
I am trouble shooting a scenario where a user complains that he cannot view the groups which he is a member of through self-service> my groups. It displays an empty list. But for some users (when impersonated them) self-service> my groups show the groups which they are members of.

I have dug into My groups module where it is having a fixed query that returns all the sys ids of the groups of which the particular logged in user is a member of. [I have checked the script include in 'scripts - Background' UI and it returns the expected result (group sys_ids)- so I can affirm that the script include in the beneath page provides the expected result]

Once, I provide the user 'itil' role he can view the groups when he selects self-service> my groups.
Can someone please advise is it a must for a user to have 'itil' role for self-service> my groups to list down the groups a particular user is a member of.

If someone can share his wisdom with me, I really appreciate it.

[XHerout]

Hello @Dush 

If I believe the ACL on sys_user_group, the user needs to have at least one role to see the groups.

Refer to the script portion in the sys_user_group.read ACL

if (gs.getUser().hasRoles())
	answer = true;
else
	answer = false;

[Dush]

I checked that scenario as well, but this specific user is having more than 10 roles. 

[Laszlo Balla]

You could always just add a new read ACL based on any condition yo want, just remember that the sys_user_group.name field also has a restriction in place, meaning you would need to add at least 2 ACLs in order for the group names to be visible for your user in he list.

[Laszlo Balla]

The answer is not (necessarily) to grant an itil role, espcially if this is otherwise not needed, and might have license utilization implications. Instead, have a look at the read ACLs configued for the sys_user_group table in your instance:

• System Security > Access Control (ACL)
• Filter for "Name starts with sys_user_group" AND "Operation = read"

Out of the box, there is an ACL on the table level (i.e. ACL name is simply sys_user_group) that grants access to the snc_internal role, but it has the script highlighted by @XHerout above. And guess what, the hasRoles() function will automatically exclude the snc_internal role, so that alone is not enough, the user should have at least one more (also note that external roles will also make this function return false, such as sn_customerservice.customer, as these customers should not be looking at stuff in the system 🙂 ).

Hope it helps!