To add to the above, am I missing something in the condition?
Basically ACL's only need to allow access once for a record to be available.
For example:
1. There's an ACL for read access that gives access if user has itil role.
2. Another ACL gives access if user is assigned_to.
3. Third one gives access to caller.
4. Now if we create a fourth one for new role.
Now when a user opens the table/record the ACL's will check if access should be given. Lets say our user has itil role, is a caller on few and has this new role.
The ACL's 1, 3 and 4 are going to return true and the user has access. The second one doesn't prevent access if something gave it on same level.
Now if we want to make sure that the new role only has access to based on our new ACL, you'll have to modify 1 and 3 as well.
Basically this could be something as simple as adding a new condition in the script:
if(!gs.hasRole('your_new_role_name_here')){
answer = true
}else{
answer = false
}So, if in case 1 the ACL now just checks if user has itil, we can add the above script to the script part of said ACL and it will additionally check that the user doesn't have "your_new_role_name_here". If they do, the ACL will instead prevent access. Same thing with the other ones. Now the new one is the only one giving access.
BTW. You can enable Security debugging to see which ACL's are giving and preventing access:
In the navigator write "Debug All Security" and click the option.
It will open up a new window and at the bottom of every page there's also a list of ACL results. There you can see whether access is given or not.
It might be a bit hard to read, but basically green arrow means access given and red is blocked:
After you're done you can turn it off by selecting "Stop debugging" from the navigator.
