- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎01-08-2018 05:05 AM
In this Knowledgebase article, the author recommends to build an On Before Query Business Rule to filter the records that should not be displayed, so the list renderer would not have to decide wether the record should be displayed. Now I don't fully understand how to code the script for this rule, as any Queries on the current GlideRecord object would trigger the Script to be run again.
The problem that I am facing is that we have to separate groups working on Security Incidents, and neither should have access to the other's data. After implementing the access restriction, the users now see the message "Rows removed by security constraint: x". What I would like them to see is their own data, without the message and any hidden rows. The current implementation is not user friendly:
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎01-17-2018 01:44 AM
Hi Leon,
You can disable the ACL for a while, use filter to see the records as per your condition. Right click on the filter to copy query and use it as an encoded query in the query business rule.
Hope this helps.
Please Hit like, Helpful or Correct depending on the impact of the response
Thanks,
Srikanth Varma

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎01-08-2018 05:07 AM
Hi Leon-Alexander,
Kindly get ACL of type read modified for Security incident table.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎01-08-2018 05:11 AM
Hi Jaspal,
thanks for the answer. ACLs are already in place, thus producing the subjected message that is to be removed.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎01-08-2018 05:08 AM
Hi Leon-Alexander,
Yes, you need to create an Before-Query business rule. Can you share what the ACL looks like that is doing the filtering based on permission? Often, if you use a script there, you can use a very similar script in the before-query business rule.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎01-08-2018 05:16 AM
Hi Chuck,
thank you for the quick response!
The ACL allows read access to users with the sn_si.basic role, additionally the following check is being performed:
var answer = global.SecOps_PermissionHelper.canReadSecurityIncident(current);
/**
* Computes if a sn_si.basic user can read a security incident.
*
* @param {sn_si_incident} si
* @returns {Boolean}<
*/
SecOps_PermissionHelper.canReadSecurityIncident = function (si){
if (this.canSeeAll()){
gs.log("Permissionhelper: canReadSecurityIncident canSeeAll returning true.");
return true;
}
//necessary to see the record on create
if (si.sys_created_by.nil()) return true;
var user = gs.getUser();
//caller / requested by can read
if (!si.caller.nil() && si.caller == user.getID()){
gs.log("Permissionhelper: canReadSecurityIncident caller/requested by returning true.");
return true;
}
//assigned to can read
if (!si.assigned_to.nil() && si.assigned_to == user.getID()){
gs.log("Permissionhelper: canReadSecurityIncident assigned to returning true.");
return true;
}
//member of assignment group can read
if (!si.assignment_group.nil() && user.isMemberOf(si.assignment_group.toString())){
gs.log("Permissionhelper: canReadSecurityIncident Member of assignment group returning true.");
return true;
}
//users on watchlist can see security incident
if (!si.watch_list.nil()){
var index = si.watch_list.toString().indexOf(user.getID(), 0);
if (index >= 0){
gs.log("Permissionhelper: canReadSecurityIncident watchlist returning true.");
return true;
}
}
gs.log("Permissionhelper: canReadSecurityIncident returning false.");
return false;
};