Advanced script on ACL - role based restrictions

[curtisr]

I have a strange issue with an advanced script on an ACL. I have a new role called "itil_restricted", which inherits "itil" as it is IT without the ability to manage change or problem. So on the create rule for the problem table I have created a new rule with the conditions of this advanced script:

if(gs.hasRole('itil') && !gs.hasRole('itil_restricted'))
   {
   answer = true;
}
else {
   answer = false;
}

The thought behind it is everyone with the "itil" role and without the "itil_restricted" role will be able to create on the problem table. What is happening is when this ACl is active no one can modify/create. So the lock down part is good, just not the when to lock down. I turn this one off and everyone has full access again.

I feel like I am missing something elementary here.

[Chris M3]

I don't see anything in particular wrong.

What you might try is adding the itil role to the ACL, and then the script is simply..

answer = !gs.hasRole('itil_restricted');

If this doesn't work, try logging !gs.hasRole('itil_restricted')

[curtisr]

I tried adding the itil role as required and changed the script to "answer = !gs.hasRole('itil_restricted');" and it produced the same result. Itil and the restricted role were both locked out from filling in the form. So I decided to do what I should have done before and debug the security and with this setup I, without the itil_restricted role, was getting a result of false.

[Chris M3 · Accepted solution]

You're an admin though. (I assume), even if you don't have the role, you have the role according to gs.hasRole

Switch it to gs.hasRoleExactly(), or impersonate a non-admin.

[curtisr]

Correct, i am an admin. I had admin overrides turned off and thought that was enough. Changed to hasRoleExactly() and that hit the mark perfectly. That was the missing piece. THANK YOU so much!

I appreciate this and the tutorial .