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!

[Mohith Devatte]

Hello you need to check like this by separating it

If(gs.getUser().isMemberOf('your group name') ||gs.getUser().isMemberOf('your group name'))

{

//set visible

}

same goes with roles also separate them into two using has role exactly

Mark my answer correct if it helps you

[Aman Kumar S]

You need to use display BR rule and scratchpad variable for this:

Add below line in your display BR 

var userMembership = gs.getUser();

if(guserMembership ).isMemberOf('sys_id_of the group') || userMembership.isMemberOf('sys_id_of the group')){

g_scratchpad.userIsMember = true;

}else{

 g_scratchpad.userIsMember = false;

}

Then in your client side script

if(g_scratchpad.userIsMember == true){

g_form.setReadOnly("u_do_not_send_email', false);

}

else{

g_form.setReadOnly("u_do_not_send_email', true);

}

[Lee Kraus2]

I appreciate the help from both of you. 

Aman, I'm not sure that I want to create any Business Rules that I would have to deal with later, I'm better sticking with just the UI Policy that was created by an outside contractor and editing it to actually do what we asked them instead of it being broken. Should I need to create business rules in the future, I will be referring to your answer though, I appreciate it.

Mohith, my JavaScript knowledge isn't super, so would you be able to explain to me the difference in using g_user.XXX() versus the gs.getUser().XXX() notations to call a user? for example, why wouldn't I be able to just say this: 

if(!g_user.isMemberOf('Service Desk') || !g_user.isMemberOf('Service Desk Leads') || !g_user.isMemberOf('Service Desk Manager')

instead of 

If(gs.getUser().isMemberOf('Service Desk') || gs.getUser().isMemberOf('Service Desk Leads'))

I'm just not clear on the differences so I don't know if your answer helps me yet. Thank you for any clarification you can give

[Aman Kumar S]

Hi @Lee Kraus 

 I totally understand the decisions of not going ahead BRs but there ways to take care of it.

As we know, the beauty of SN is to provide you multiple ways to solve a problem statement and we should go with the once that is most optimal solution.

Having said that BR and client script is one way to get information from server, apart from it, there is another way you can work it out. 

Emphasizing on the solution proposed above using display BR is one of the preferred way to achieve this.

If you strictly against it, you can use below approach which aligns with your requirement.

make state field as read-only, when the logged in user is not a member of the assignment group