That depends. If your requirement is to simply restrict visibility, then you need to only update the READ rules.
Let's look at the previous script I wrote.
In it we set the initial value of the ACL to false.
Then if the user is a member of the "super_group" they get read access.
If not, we then check if the current "restric_access" field is set to true. If it is we check if the current user is in the "u_vsible_to" field and give them access. If not, we then check if the user is in the "u_hidden_from" field and block access. If they're not in the super_group, access is not restricted and the user is not in the hidden from field, then we can apply the original ACL logic.
var answer = false;
if (gs.getUser().isMemberOf('super_group')) {
answer = true;
}else if(current.restrict_access == true){
if(current.u_visible_to.indexOf(gs.getUserID()) > -1){
answer = true;
}
}else if(current.u_hidden_from.indexOf(gs.getUserID()) > -1){
answer = false;
}else{
//Original logic
}
You basically need to just modify the original ACL to fit in the else part of the code or it might go there without problems directly.
The ACL won't really affect performance either if you don't have multiple overlapping and looping ones.
You can test the code by running it in background
https://YOURINSTANCE.service-now.com/now/nav/ui/classic/params/target/sys.scripts.modern.do
Then run this code:
var current = new GlideRecord('TABLE');
current.get('SYS_ID');
var answer = false;
if (gs.getUser().isMemberOf('super_group')) {
gs.info("inside super_group check");
answer = true;
}else if(current.restrict_access == true){
gs.info("inside restrict_access");
if(current.u_visible_to.indexOf(gs.getUserID()) > -1){
answer = true;
}
}else if(current.u_hidden_from.indexOf(gs.getUserID()) > -1){
gs.info("inside hidden from check");
answer = false;
}else{
gs.info("inside original else check");
//Original logic
}
gs.info(answer);
Just replace TABLE with the table your ACL is run on and the SYS_ID with one of the records you want to test this on and it will print out the true of false depending on whether access would be given.
Now you can test this by adding your user to the super_group and this should print out "inside super_group check" and true.
Then you can remove your user from the group and set the record to restricted and add your self into the visible to field. Again you should get "inside restrict_access" and true. Now remove yourself from the field and you should get the same log and false.
Then set the record to not restricted and add yourself to the hidden from field. You should now get "inside hidden from check" and false.
Finally remove yourself from the field and check if you get "inside original else check" at the end.
Do note that this will always return false if restrict_access is true and you're not on the visible to field and it will not go to the else part of the script.
You can try query rules as well but they get a bit hard with this logic.
Basically query rule is just an addQuery on a GlideRecord query.
Imagine trying to build GlideRecord query where you return all records where restricted is true and you're on the visible to field and where you're not on the hidden from field.
You'd need to apply additional logic like
"If member of super group -> Skip"
"Else restricted is false and I'm not on the restricted list OR restricted is true and I'm on the allowed list."
Well, the OR here might break query rules for you. It did that to me before, but I haven't tried in new versions, but I'll assume it's still broken.
NOTE! You can use regular or, but not the "bigger" or (on top) seen here and that's what you'd need to use for your query.
