Trying to get a custom field to show up on Incident form only when the logged in user is part of a specific group

[Lee Kraus2]

In our instance, we had a previous contractor input a field and have it show up based on role, but the problem is that it shows up only for admins, and we would like it to show up for 3 specific groups as well. 

Here is their code:

This code seems to make it so that only users that have both ITIL and the admin role can see the field. All others can't see this field. I tried doing this to change it, but I think my issue is that I don't know how to make it read "if user is in these groups, then show the field". Here's my code massaging below:

I'm not sure, but I feel that the argument in Line 2 is an AND operator (like they need to be members of all these groups for it to show up), but either way, I can't seem to get my field to disappear now no matter what group the users are. 

Can someone help me with my script to make it so that those 3 groups in my code are the only ones who see the Do Not Send Email field I have on the Incident form? 

Thank you for your assistance!

[ChrisBurks]

Hi Lee,

The reason why you can't just use g_user.isMemberOf is because that method isn't available in that object. Unfortunately ServiceNow did not provide it when they created that object.

However, it is available on gs.getUser().

The downside to this is that "gs" isn't available in a client side script. It has to be used Server Side. This means that you would have to use a Script Include marked as Client callable if you want to keep this within a UI Policy.

[Uncle Rob · Accepted solution]

You're getting some questionable advice.  
Customizations of this nature should look to ROLES first before GROUPS.

You're talking about an exception to something that is governed by process.  "Because of this process, people of this type should see the data, and other people should not see the data".  That's within the governance of ROLES, not GROUPS.

Make a new role(s), apply those roles to the Groups in question, handle the configuration via ACL, NOT some crazy script include that's group dependent.

Yes, it will take longer, but it is far saver and more governable.

[Aman Kumar S]

I see your point what you are suggesting here, but what makes me uncomfortable about this we go ahead with creating a new group and role for every enhancement that we build, with time, it will to a point that it becomes very difficult to maintain.

And I totally agree there with you for such cases, ACLs are the preferred way to go, but to also understand, how many more roles and ACLs we can on top, is the right amount, would love to hear further on this.

[Uncle Rob]

You're already past the threshold of "doing X for every set of people" by doing it for every group that wants it.

You'll actually discourage the behavior by forcing it to be a *process* modification before a system one.

"The process does not say that this group has to fill out a certain field.  Adjust the process documentation to facilitate the new role".

If you don't do this, you just stack up the inevitable "wobbly tower of $&%@" the next resource is going to have to deal with, since THEY don't know there's 100,000 configs that are group specific.  But they WILL be curious about all the roles on the incident table.

[Lee Kraus2]

Thank you for your answer, I do appreciate it. I was thinking about it this weekend (didn't see your answer until now), but looks like we both agree the other info I was getting was a bit suspect. I didn't want to make too many crazy back end changes and I think just making a role and assigning it to the 3 groups I have that need to see this field will be the way to go. then using that "hasRoleExactly" will make more sense, and it's a simple update to the code.

My only question is if I have groups already, why wouldn't that work? I know that no matter what, anyone I put in the Service Desk group is going to need to see this field, and it keeps me from adding anything else that might cause conflict in the platform. (I get that creating a role and adding to said group is how the users are going to get the role and then how the UI Policy is going to filter out who can and can't see the field, I'm more just asking for clarification on why just choosing the group is not possible in this case, or not best practice)

Thank you again for your help! I'll try this role creation route in the mean time and see what happens.