I
often get the request to set up access for group managers to be able to manage the members of their groups in ServiceNow. This configuration isn’t too difficult to set up but it does involve a few different pieces. It’s also important to consider your group setup in your system before allowing access in this way. If you are bringing in group memberships from a data source like LDAP for example, the last thing you want is to have your managers manually changing those group memberships within ServiceNow. The configuration shown below could be easily customized to allow access only to non-LDAP groups if you needed to do both however.
This solution requires you to modify the out-of-box ACLs for the ‘sys_user_grmember’ table. You’ll also need to modify the ‘Omit Edit Condition’ field for the ‘Group Members’ related list on the ‘Group’ form. These configurations are outlined below.
The following script can be used within your Write and Delete ACLs on the ‘sys_user_grmember’ table. No other roles or conditions are necessary for this configuration.
if(gs.hasRole('user_admin') || current.group.manager == gs.getUserID()){
answer = true; //Allow access if user has 'user_admin' role or is group manager
}
The create ACL works a little bit differently because we don’t have access to ‘current.group.manager’ before the record is created. Because of this, you need to open up create permissions to the role that your group managers will have. Typically these managers will have the ‘itil’ role anyway so you can just set up your ‘create’ ACL with the ‘itil’ role defined in the related list at the bottom of the ACL.
Opening up the create ACL is necessary for this configuration to work, but needs to be backed up by some additional security in the form of a ‘before’ business rule. The business rule performs a secondary check on insert/update of the group member record to ensure that the user is actually a group manager or has the ‘user_admin’ role. If not, it aborts the insert/update and alerts the user.
Name: Restrict Changes to Group Managers
Table: Group Member [sys_user_grmember]
Name: Restrict Changes to Group Managers
Before: True
Insert/Update: True
Script:
if(!gs.hasRole('user_admin') && current.group.manager != gs.getUserID()){
//Abort the insert or update
gs.addErrorMessage('You do not have permission to modify this group membership.');
current.setAbortAction(true);
}
})(current, previous);
The final piece of controlling ‘Create’ access is to limit the visibility of the ‘Edit’ button on the ‘Group Members’ related list on the ‘Group’ form. You can manage this by right-clicking the related list header and selecting ‘Personalize -> List control’ from the context menu. You can place this script in the ‘Omit Edit Condition’ field to restrict visibility of the ‘Edit’ button on the related list to those who have the ‘user_admin’ role or are listed as the manager of the given group.
if(gs.hasRole('user_admin') || parent.manager == gs.getUserID()){
answer = false; //Show the 'Edit' button if user has 'user_admin' role or is group manager
}
answer;
That should do it! You may also want to create a ‘Groups’ module that is available for the role that your group managers have. This will allow your group managers easy access to the groups in the system (and with a filter access to the groups that they manage).
Mark
I tried to add this functionality to our instance, but I’m seeing a syntax error when I add the scripts to the ACL and the Edit condition.
Error:
Problem at line 5 character 1: Expected an assignment or function call and instead saw an expression.
answer;
That’s a syntax checker issue. The record should still save though. You should also be able to get it to work (without the syntax error) by removing the last line of the script. I’ve modified the scripts above to reflect this change.
Nice, elegant solution and easy to implement. Thanks for another great tip, Mark!
Thanks for using it! It’s a lot more fun when I know that people have found a use for a solution. 🙂
I’ve tried to implement this in the demo site but it’s not working. Has there been any updates since Dec 2010 to make this work?
This works fine for me when I set it up on demo. Make sure you edit the existing write, delete, and create ACLs for the ‘sys_user_grmember’ table. If you follow the instructions it should work just fine.
This was awesome and works great, thanks!
I also stole this and modified it so that group members can modify information in their own group; however, I would like to restrict their access to being able to modify just two custom fields without having to create an ACL for each field. Any suggestions?
var answer = true; //Restrict access by default
if(gs.hasRole(‘user_admin’) || (gs.getUser().isMemberOf(current.assignment_group))){
answer = false; //Allow access if user has ‘user_admin’ role or is a member of the current group
}
You’ll probably need at least 3 total ACLs then. You’ll need one ‘sys_user_group.*’ field level ACL that locks down write permissions to the entire record – probably to everybody but admins or something. Then you could use a script like you’ve got above in a couple of field level ACLs for just those fields that you want to open up.
Finally figured out what I was doing wrong, incase someone else wants to do this. Mark is correct about needing an ACL to give write only permission by default to admin, and an ACL for each field that needs write access, or just one .* ACL if you want group members to be able to write to all fields in the group. My problem was with the script in my previous post.
The correct script is as follows:
var answer = false; //Restrict access by default
if(gs.getUser().isMemberOf(sys_user_group.name)){
answer = true; //Allow access if user has ‘admin’ role or is a member of the current group
}
Hi Mark,
Thanks so much for these instructions – this is working great for us!. I have just 1 question in regards to your very last statement about creating a ‘Groups’ module to make it easy for managers to get to their groups. You recommend making that module available to whatever roles our managers have. In our case, managers do not have a special role…they share a role with all other IT users (similar to the itil role). Is there a way to hide/display this module in the application navigator based on whether or not they are a group manager….basically, using the same script as we’re using in the ACL’s?
var answer = false; //Restrict access by default
if(gs.hasRole(‘user_admin’) || current.group.manager == gs.getUserID()){
answer = true; //Allow access if user has ‘user_admin’ role or is group manager
}
thanks,
Kari
Good question, and I’m glad you’re liking the solution. Unfortunately, modules can only be restricted by role. You’ll need to give your managers a separate role in order to show the module to them, but not to regular users.
Hi Mark,
Would it not be possible to restrict access to the modules through the use of a query rule, much the same was as it can be used to restrict access to applications via query. I have this running on some of our customer instances, but havent tested it on the actual modules.
Thanks
Shaun
You’re correct that it’s technically possible, but the problem is that none of the structure is there to restrict access on a per-module basis based on anything but a role. The before query business rule restricts access to modules, but it doesn’t have anything to say which module to restrict access to. If you did use a before query business rule you would need to build out some additional fields, or add a bunch of clunky conditions to check the titles of the modules you wanted to restrict in a certain way. If users already have one role, then it’s usually much easier to just grant them one additional role and be done with it.
Hi Mark,
I have tested this on demo.But,the user having no user_admin role can’t see the groups.So,will u please help me to sort out this issue.
Thanks
Anoop
The article assumes that the managers have the ‘itil’ role. I’ve just tested this out on demo22 with ‘ITIL User’ and it works correctly. You can review the setup in that instance to get a working config.
Is there a way to modify the code, so that it looks if you are the manager of the group or a member of the group?
Sure. Take a look at the ‘isMemberOf’ method here…
https://servicenowguru.wpengine.com/scripting/user-object-cheat-sheet/
The general syntax in an ACL would probably be something like this…
Hi,
I tried using this in my ACL script, but it is returning FALSE always even though user belongs to the group. I am trying to impersonate the user and I see this value always returning FALSE.
Thank,
Thank you so much! Now our managers can modify their own group memberships!
John
We’ve noticed in our instance, that while users are able to add users, when they attempt to remove and save the action. Nothing changes….is that a bug?
Probably just a mis-configuration. If you can’t remove the users from the group it probably means that your delete ACL on the ‘sys_user_grmember’ table isn’t allowing access.
Mark is right – I had to add that into my ACL because I was having the same issue. Works like a charm and adding in a “My Groups” module with a filter for only stuff of which that person’s the manager is going to be so helpful!
Hi Mark,
Thanks for a beautiful solution. I tried this and created 3 ACL create, write and delete. As you suggested the script for write and delete is the same. I am trying to make the users of the groups to be able to add/delete members.
When I do edit, I am able to add but when trying to remove from the slushbucket, nothing is happening.
Can you suggest why?
Thanks,
Thank you. The only thing I can think of is that you’ve got some other Delete ACL on the ‘sys_user_grmember’ table that is preventing the delete. You can debug ACLs to help identify which one might be causing the problem.
I am noticing that the manager can add and remove groups from any user form. Is there a simple way to restrict using the New and Edit buttons on the related Groups tab on the User form?
I asked before taking the time to look into it. I personalized the list control on the User record for related Groups and added the role user_admin to both New roles and Edit roles. That appears to do what I want. Otherwise the manager (and presumable other itil users) could do strange things like create a new group (with all empty fields) and associate it to the user. Or even worse, they could add and remove the user to and from any other group.
Thanks for this excellent solution. Now I won’t have to be the full-time Assignment Group editor.
Thank you Shawn,
I have discovered the same. Horrible when roles are assigned to groups :-).
Hi,
Could you please write on this wich version it applies to, I think it works a bit different on Eureka.
Thanks,
Annette
Should work on any ServiceNow version without issue.
On the Omit Edit Condition, in Fuji release, I had to create a function around this process otherwise it was I was unable to save the form. Unfortunately, it’s still showing the edit button on every group.
function checkgroupmgr(){
var answer = true;
if(gs.hasRole(‘user_admin’) || parent.manager == gs.getUserID()){
answer = false;
}
return answer;
}
checkgroupmgr();
suggestions?
Thanks,
— Adam
I’m not sure why it’s not working in your instance but I’ve never seen an issue with this and I’ve got it running in our Crossfuze production instance successfully right now. No function required and the script exactly as shown.