- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-13-2020 10:38 AM
Adding roles to a group is usually immediate, but today in a non-Prod instance, this information banner is popping up and the roles are not adding. The group(s) in question have less than 10 members and the role being added is not multi-tiered. It has been over an hour (I went to meeting) and the role isn't there. Other roles on other groups have worked, but this message always appears. This is not a new role.
Where is this 'job' and why isn't it running/completing?
Solved! Go to Solution.
- 19,473 Views
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-23-2022 08:17 AM
Hi yes, we had to open a HI ticket and SNOW gave a workaround, stating that that's how it's supposed to work... here's the response.
"I have completed my investigation on this issue and have raised a problem for this (PRB1547123) which is now associated to this case.
The cause of the issue is a combination of two settings:
1) The admin role does not have sn_hr_core.admin role in the Contained Roles on your instance:
{link to oshkosh instance}
2) The system property: glide.ui.schedule_slushbucket_save_for_group_roles is set to true.
As a workaround, to add a user to a group with HR roles, follow the steps below:
1)Set the system property: glide.ui.schedule_slushbucket_save_for_group_roles to false
2) Add the user to the group
3) Set the system property: glide.ui.schedule_slushbucket_save_for_group_roles to true
4) Clear the cache for the system property to take effect."
In summary: For us, it's only happening to my HR groups and groups with roles.
In the environment, go to sys_properties_list.do. Find glide.ui.schedule_slushbucket_save_for_group_roles - should be set to true. Open it and set it to false.
Then make the updates to your groups. Refresh the page to make sure the users were added properly.
Return to glide.ui.schedule_slushbucket_save_for_group_roles again and set it back to true.
I hope that helps. Good luck,
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-16-2023 07:33 AM
I've got the same issue today. Tokyo. Never seen this before?!?!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-21-2023 02:53 AM
@dawnbrady @cherylbrownlee did anyone found solution for this we are in the tokyo release we are facing the same issue.
also we are facing many issue after tokyo release
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-21-2023 06:31 AM
I did this one:
In the environment, go to sys_properties_list.do. Find glide.ui.schedule_slushbucket_save_for_group_roles - should be set to true. Open it and set it to false.
I reported this to SN and they said that it appeared that I had already made the fix. I told him the Community said that I should reset back to TRUE when finished making a change, and they said that I didn't have to. So might will stay as FALSE. I don't have a lot of people to add to groups.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-21-2023 06:43 AM
Nice. Yes, my company has to set it back to TRUE in order for something else we have built to run. Glad this helped.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-03-2023 07:43 AM
I just ran into this issue where HR team members who have rights to edit/update groups are no longer able to edit HR groups; yet they still have access to edit non-HR groups.
While I was typing up a new Case on HI a self-service recommendation popped up: https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0780713
Which pretty much sums up the issue because, for some unknown reason, SN decided to restrict edits of HR groups to just users that hold the "sn_hr_core.admin" role.
To me this is not a sound move as it means either we start granting the role to more people (not a good idea) or all group edits that were done "internally" to the HR department is now going to have to be routed to the admin/dev team; which will add in additional delays.