- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-23-2024 11:23 AM
Hello all,
Per a recent Health Assessment, we received feedback from ServiceNow to remedy the below ACL on the sys_attachment table. Is there a way to get the same behavior without the usage of a "GlideRecord", per the notes from the Health Assessment to NOT use GlideRecord???
Notes Per Health Assessment: Avoid database lookups in Access Control rules, as this can significantly impact performance.
answer = getAttachmentReadAnswer();
function getAttachmentReadAnswer() {
if (current.table_name.nil())
return true;
if (current.table_name == 'ni')
return true;
// If the attachment is from live feed,
// grant it the read access
if (current.table_name.indexOf("live_profile") > -1 || current.table_name.indexOf("live_group_profile") > -1)
return true;
// Remove Prefix
var tableName = current.table_name;
if (tableName.startsWith("invisible."))
tableName = tableName.substring(10);
else if (tableName.startsWith("ZZ_YY"))
tableName = tableName.substring(5);
var parentRecord = new GlideRecord(tableName);
parentRecord.setWorkflow(false);
if (!parentRecord.isValid() || !parentRecord.get(current.table_sys_id)) {
if (current.sys_created_by.equals(gs.getUserName()))
return true;
return false;
}
return parentRecord.canRead();
}
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-23-2024 01:07 PM
You are instantiating a GlideRecord object, but not executing a GlideRecord query, which is the intent of this guideline, so I would say this is not a major concern as a finding since you are not executing what could be a time/load intensive query of the database.
I'm not sure what this GR is needed for though. setWorkflow is not doing anything in this case, so you can get rid of that. That just leaves checking if the table_name is valid and if the table_sys_id is a legitimate record on that table - for what purpose? What if you scrapped all that and just returned true if the current user attached the file, otherwise return false in this section? The final return is just evaluating if the current user (?) can read the record that the attachment is attached to - if they can't, then by what means are they reading the attachment?
Having said all that, in an out of the box PDI there are nearly 400 ACLs that contain GlideRecord, so if ServiceNow can't play by the rules, it makes you wonder how important of a rule it is.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-23-2024 01:07 PM
You are instantiating a GlideRecord object, but not executing a GlideRecord query, which is the intent of this guideline, so I would say this is not a major concern as a finding since you are not executing what could be a time/load intensive query of the database.
I'm not sure what this GR is needed for though. setWorkflow is not doing anything in this case, so you can get rid of that. That just leaves checking if the table_name is valid and if the table_sys_id is a legitimate record on that table - for what purpose? What if you scrapped all that and just returned true if the current user attached the file, otherwise return false in this section? The final return is just evaluating if the current user (?) can read the record that the attachment is attached to - if they can't, then by what means are they reading the attachment?
Having said all that, in an out of the box PDI there are nearly 400 ACLs that contain GlideRecord, so if ServiceNow can't play by the rules, it makes you wonder how important of a rule it is.