How does the ApproverUtils script include ACL work

[Andy H1]

According to the information provided by glennpinto's answer in this link, if there are field level ACL's defined on a table then a role having only a tableName.none ACL will not have visibility to those fields.  The role would need its own ACL's on those fields to gain visibility into them.  In my testing, this appears to be true.

Separately, this link talks about an ApproverUtils script include introduced in Madrid Patch 4 that is being called from an ACL.  The script include appears to evaluate visibility for approvers.  I've encountered this in the sc_task table where there is an ACL defined for sc_task.none.  There are no roles assigned to the ACL, but it calls ApproverUtils which will apply some logic before returning a true/false.  This appears to be working as a user with only the approver_user role is able to view all fields in the sc_task table.

However, there is also an sc_task.* ACL on the table granting access to all fields to the itil role.  If I understood the information in the first link correctly, this ACL should essentially nullify read access to the fields on the table for the sc_task.none ACL described above since no approver roles have field level ACL's on sc_task.

Can anyone explain to me how this works?

[Chris McDevitt]

Andy,

I believe that that answer lies in the description of the 'ApproversUtils':

"Utility to check if Approvers can read records they are approving. g_approval_form_request is set in the approval_summarizer_default UI Macro."

I appear as if this ACL purpose is to work with the UI Macro to validate if there person approving can view the record. (Via the UI Macro)

Go ahead and smash that Helpful 👍or Correct ✅button!

[Andy H1]

Thanks for responding!  I think that perhaps my question wasn't written as clearly as I hoped.  It's not so much the logic employed by ApproverUtils that I'm confused about, but why access is being granted in the context of other ACL's in play.

For example, below is a screenshot of the ACL that's calling ApproverUtils.  Note that it is an ACL with no field specified.

According to glennpinto's explanation (first link I provided in my question), if this is the only ACL on sc_task it would provide visibility to all the fields on the table to anyone that ApproverUtils returns 'true' for.

Also according to glennpinto's explanation, this ACL would cease to provide visibility to any fields where a field level ACL exists on the same table.

In my instance, there exists such an ACL (below), granting read access to all fields on the table to the itil role.

This appears to in contradiction to glennpinto's explanation of how ACLs work (which I verified to by accurate in my own testing).  I'm hoping to gain an understanding about why the sc_task.none ACL that calls ApproverUtils continues to provide visibility to the fields on the table when there's an sc_task.* ACL active on the table.

[Chris McDevitt · Accepted solution]

Ok,

Let's see...

The short answer is that UI Pages / UI Macros are built(executed) in the background/system context and not in the user context. Everything you know about ACL's is true, in the correct context.

So... technically, sc_task.none and sc_task.* do not come into play here....

Consider the test user 'Abraham Lincoln', who does not have any Roles for Security Incident. Abe just clicked on a link for a UI Page (that I mocked up) that will display 10 security incidents (The Security Incident Table most differently has ACL restricted on the Table/Record and Fields levels).

[Andy H1]

Thanks Chris, I had also done some reading since your first reply on how UI Macros work.  Together with your replies, it makes sense now.  Thanks!