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.

[curtisr]

I had to change the approach a little from the hasRoleExactly(), but it still got me in the right direction.

This is the script I ended up using with success:

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

Now itil & admin roles have access and itil_restricted does not.

Thank you again

[Dave Smith1]

Is there a gs.hasRoleExactly() method?

I can't find documentation of it, and my experiments suggest it's a method of GlideUser but not GlideSystem.

[curtisr]

The hasRoleExactly is outlined on wiki in the same method as hasRole, so I am pretty sure it would work. I did end up going with another approach to achieve what I wanted and not have the admin roles access restricted by inheritance.

Here is the script I ended up going with on the ACL.

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

So if the person has the admin role they will always have access since they would technically have the itil_restricted role and lose access.

[Dave Smith1]

Are you confusing g_user with gs?   I tried gs.hasRoleExactly() and it failed any test - as far as I could see, there wasn't a hasRoleExactly() method for GlideSystem (server-side), only for GlideUser (client-side).

My approach was similar to yours - I ended up having to check for admin first, and if they had admin then all bets were off.   If the admin test failed, then gs.hasRole() would accurately return true or false, depending if they held that role.

(I do feel that the hasRole() test is flawed if "admin" role seems to encompass every role)

[curtisr]

I bet your right and this is probably why I went a different route. Its been a while and a lot has happened since this one. I agree that the hasRole is flawed.