Can anyone explain the Read ACL on sys_journal_field installed by Human Resources: Core?

[Steve Arnold3]

We recently installed the HR Service Delivery plugins in our production environment, and noticed that an ACL it created has broken our SnowMirror replication of the sys_journal_field table. We're working with the vendor on it, but I wanted to see if anyone could explain the ACL to me. Looking at a personal developer instance, the ACL is identical to what is in our production instance, so I know we didn't modify it in any way. Here are the particulars (screen shot attached):

Type: record

Operation: read

Name: sys_journal_field

Script:

answer = getJournalReadAnswer();

function getJournalReadAnswer() {
	if (!current.name.startsWith("sn_hr_core"))
		return false;
	
	var impersonateCheck = new sn_hr_core.hr_CoreUtils().impersonateCheck();
	if (impersonateCheck)
		return false;

	var roles = new hr_Utils();
	if (roles.checkUserHasRole("sn_hr_core.admin"))
		return true;
	else
		return false;
}

From what I can tell, the ACL isn't stopping us from accessing journal entries directly in records that are in non-HR tables, but it seems like the return statement on line 5 should be true instead of false...unless I'm just crazy. If I, having both admin and sn_hr_core.admin roles, go directly to sys_journal_field.list, I see get the security constraints message. I am able to see entries for tables starting with sn_hr_core tables, but the rest are restricted.

Any thoughts on this (the ACL, not me being crazy)?

[Jaspal Singh]

Hi Steve,

ACL calls for script include: hr_Utils. Can you confirm if this was not modified from your end or missed an update that came in if instance was upgraded or plugin was installed.

Thanks,

Jaspal Singh

Hit Helpful or Correct on the impact of response.

[Steve Arnold3]

Yes, I have just confirmed that our production version of the script include is exactly the same as the OOB one in my personal developer instance.

[Steve Arnold3]

Another thing I tested, based on an old community post, is retrieving sys_journal_field entries via the API from the URL. Using the URLs below, I get the results displayed:

Instance without HR installed:

URL: https://<myinstance>.service-now.com/api/now/table/sys_journal_field?sysparm_query=element=comments^element_id=f5676f5cdbb7e38003ad96e5b9961911

Output:

<response>
<result>
<sys_id>10c2d5cbdb53b7007515bb6f68961913</sys_id>
<sys_created_on>2019-08-20 17:54:41</sys_created_on>
<name>incident</name>
<element_id>f5676f5cdbb7e38003ad96e5b9961911</element_id>
<sys_tags/>
<value>Test additional comments</value>
<sys_created_by>US6875999</sys_created_by>
<element>comments</element>
</result>
</response>

Instance with HR installed:

URL: https://<myinstance>.service-now.com/api/now/table/sys_journal_field?sysparm_query=element=comments^element_id=9db41876db5fb7009bccbb6f689619a7

Output:

<response/>

However, in both cases, through the UI, I am able to see the comments (see attachments).

[Steve Arnold3]

Oh, and almost the exact same ACL exists on sys_audit, which also causes issues with reading the table via API. I do have an open HI ticket for these ACL issues. I will post the results.