Allow approvers to see RITM details in ESC - Behavior of ApproverUtils

Oliver Anderson
Kilo Sage

I'm stuck on an issue where approvers are unable to see the details of RITMs they're approving within Employee Center. There are many posts on this already, but none of them quite answer my question of the behavior that's happening out-of-box here.

 

Current behavior:

Users with no roles who are an approver of a RITM are able to see the details summary in the platform (back-end) view, but not able to see the details on the HRM Todos Summary widget in ESC.

Expected behavior:

Users with no roles should pass the ACL allowing them to view details of an RITM they are approving in both the platform (back-end) view and in ESC.

 

I know there's an ACL on sc_req_item that calls the ApproverUtils script include (I've added logging for visibility):

 

var ApproverUtils = Class.create();
ApproverUtils.prototype = {
    initialize: function() {},

    canApproversRead: function() {
        var transaction = GlideTransaction.get();
        var targetRecord = JSUtil.notNil(transaction) ? transaction.getRequestParameter("sysparm_record_target") : null;
        var result = false;
		gs.log("[0] targetRecord: " + targetRecord,"approverutils");
		gs.log("[1] canApproversRead called","approverutils");
        if (typeof g_approval_form_request != "undefined" && g_approval_form_request == true) {
			gs.log("[2] If block 1 passed","approverutils");
            result = true;
        } else if (targetRecord != null && targetRecord == "sysapproval_approver" && targetRecord != current.getTableName()) {
            var target = new GlideRecord(targetRecord);
			gs.log("[2] If block 2 passed","approverutils");
            if (target.get(transaction.getRequestParameter("sys_id")) && target.canRead())
				gs.log("[2.5] If block 2.5 passed","approverutils");
                result = true;
        } else if (!current.nil() && transaction !=null && (targetRecord == current.getTableName() || transaction.getRequestParameter("sys_popup_direct"))) {	
            var sourceTable = transaction.getRequestParameter("sys_popup_direct") ? transaction.getRequestParameter("sysparm_table_name") : targetRecord;
			gs.log("[2] If block 3 passed","approverutils");
            result = this.verify(sourceTable, current.getUniqueValue(), gs.getUserID());
        }
		gs.log("[3] Result: " + result.toString(),"approverutils");
        return result;
    },

    verify: function(sourceTable, documentId, userId) {
        var gr = new GlideRecord('sysapproval_approver');
        gr.addQuery('approver', userId);
        gr.addQuery('document_id', documentId);
        gr.addQuery('source_table', sourceTable);
        gr.query();
		gs.log("[2.5]Verify function found: " + gr.name,"approverutils");
		return (gr.next());
    },
    
    type: 'ApproverUtils'
};

 

 

If a user with no roles is linked to an approval record for an RITM they are approving in the backend, they are able to pass the ACL and see the details summarizer to the variables of what they're approving:

OliverAnderson_1-1726063232887.png

 

If a user with no roles goes to their tasks in ESC to view an approval, they are not passing the same ACL, and therefore, are unable to view the details of the RITM they are approving:OliverAnderson_0-1726061840931.png

 

Now, I'm not great at reading the OOB scripts that someone who gets paid way more than me wrote, but I think this is happening because of this line in canApproversRead():

canApproversRead: function() {
        var transaction = GlideTransaction.get();
        var targetRecord = JSUtil.notNil(transaction) ? transaction.getRequestParameter("sysparm_record_target") : null;

It looks like the URL parameter in sysparm_record_target is pulling null in ESC, because that HRM Todos Summary widget doesn't use/change the URL in order to display data, whereas in the platform view, that parameter is present, so the script actually hits one of the "if" statements that leads to searching for that RITM in the sysapproval_approver table.

 

So I guess my question is, where do I go from here? This seems like such a simple oversight for out-of-box approval functionality. Am I just using the wrong widget on ESC? It seems like I'm going to have to create a custom ACL on sc_req_item, but I really don't want to use a GlideRecord query within the ACL script to verify if the logged in user is an approver on that RITM for performance purposes. Is there some sort of configuration I'm missing?

 

Any ideas would be welcomed. And please don't suggest giving approver_user to the user - this doesn't fix the issue, and the goal is to allow anyone to view RITM details on RITMs that they're approving through email. I'm unable to give approver_user to everyone in the organization.

 

Thanks!

2 REPLIES 2

SatyakiBose
Mega Sage

We are facing a similar issue.

The issue that I have faced is, even if the user has approver_user role, the RITM details are not visible in the HRM Todos Summary widget.

However, if the user navigates and checks the same approval using the My Approval widget, the RITM details are visible.

Jonatan Horvath
Tera Contributor

Hi Oliver, did you find any solution to this issue?