We are implementing Approval Delegations for Change and I'm trying to configure a notification so that an email is sent to Change approvers Approval Delegates, which I've been given to understand is $L.delegates (if the jscall("ApprovalDelegationGroups.checkDelegation") is part of the notification condition), but so far have had no success. I've also tried in my OOB instance of the same version (SM9.33) and for a regular Change it did not send an email to the $L.delegates either. Has anyone successfully got these $L.delegates notifications working and is there anything special I need to do for them to be produced?
If I remove the jscall as part of the notification condition and change the recipient to a hard coded value, the email goes to the address hardcoded as the recipient, but the minute I put the jscall back in and change my recipient to $L.delegates then no email is produced. I am testing where the new operator in the current.pending.groups has definitely delegated their approvals and they show in the delegates Approval Queue.
I have rtecalls to print messages from the notification records, so I know it is being called, and since the issue seemed to be what was returned from the jscall("ApprovalDelegationGroups.checkDelegation") ScriptLibrary record, I had put a few print() statements there and immediately got results the I didn't expect. My first print statement was just before the "if" statements that check the vars.$L_file.file_name. When I put print(vars.$L_file.file_name); in the line before this group of statements it returned "null". This seems wrong, but perhaps you can tell me if you get the same. I also put a print statement at the end of the function right before the line " vars.$L_delegates=moreOperators;". I put print(moreOperators); and got "undefined", but perhaps I'm suppose to write my print statement differently since it would be an array? Perhaps you can suggest if there are other places where it would be useful to add a print statement?
I had been thinking the same as you John, that maybe something I had in my SM7 environment carried over when I upgraded to SM9.33, or maybe I could test if it was working before the upgrade, but when I checked my old environment Approval Delegation wasn't even there, so I've kind of eliminated that as a useful area of investigation.
Try to put print just before last line having 'return' , print("delegated " + vars.$L_delegates);
print(moreOperators); should also print the value irrespective of array.
This delegation feature not exists till 7.0x and added in 7.1x, also the function [checkDelegation()] we talking about is fix for some QCR, mentioned just before it in SL. //This function is the fix of QC48598(Emails do not get sent out to the approval delegates as the documentation says). Find the delegations and store them //in the $L.delegates.The notification should add another msg to send the email.
Till 9.21, there is still no such mail delivers.
____________________________________ Assign Kudo, if found post useful and mark it accepted if solves the issue.
I figured out why my notification wasn't going to $L.delegates
Sorry Audrey, my response above was incorrect. On re-testing in 9.33 OOB, delegate notifications are not working. I'm sure we got these working from ChM notifications at my last customer, but I'll have to look into what we did. I know we didn't base the notification off the Approval record (though a rather clever solution).
HOWEVER, I believe there is another defect in the OOB script:
So far as I can tell, it will only notify delegates for an operator-level delegation, not group-level delegations.
I split out the script to hardcode the tables and call the module-specific script from the notification def.
The Delegations that applied to the test record were all for group-level approvals, not operator-assigned approvals.
I could not get it to work, but it did work only if a pending approval was for an individual operator that had delegated to another operator (not a group approval).
Looking further, the query built by checkDelegation is incorrect. It queries: var query="Approver isin "+ system.functions.str(vars.$L_file.current_pending_groups);
BUT Approver is always the ID of the oringinal approval operator and--if groups are assigned--the group-level delegation will not return a notification for delegates (because the operator IDs are not listed in current.pending.groups, only the group names).
var query = "AppGroup isin "+ system.functions.str(vars.$L_file.current_pending_groups)
will consistently work, whether the pending approval is an operator-level or group-level delegation (because current.pending.groups includes both groups and approvals assigned to specific operators such as owner in $L.file).
The AppGroup field identifies the group/operator for which delegation is assigned, while the Approver field is the individual operator for whom those rights are assigned.
Impact: Confirm that your workaround notifies delegates not only for approvals pending for a specific operator, but also for those pending for groups.
Adding the notification to the "Approval Added_1" notification worked immediately, but I can't produce the email that I want with the fields in the Approval record, so I experimented with adding it to my ChM notification record and just changing the if() statement in the ScriptLibrary record (ApprovalDelegationGroups.checkDelegation) so that it doesn't look for a file.name of cm3r, and instead looks for the number starting with "CM". This evaluated correctly to produce the query which then produced my $L.delegates list and correctly sent my notifications, but it just seems strange to me that I have to modify this script at all. I would have thought it should have been configured to work using the ticket as $L.file since there are a few OOB ticket based notification records that call this ScriptLibrary record and if the if() statement that produces the query references a field that doesn't exist I don't see how it will ever produce the $L.delegates list.
If you found a better way than modifying the script I would be very interested to know it.