Use PDIs? Take our 5-minute survey to help shape the PDI roadmap.

Add a custom field to Todos HR Case Approval widget

Padraig O_Kane1
Tera Contributor

I have a requirement to introduce a Second Approver field on the HR Case Approval widget that is then passed to the Approval record and updated. I have cloned the out of the box widget and made the following changes (see screenshot 1 where I have introduced the new field, server logic to pull back a list of users and broadcast logic to check for changes to the field - this is needed as the widget relies on an embedded widget where the Approve/Reject buttons are located). The issue I am having is passing the new field value to the embedded widget (see screenshot 2 where I have introduced a listener for field changes). I have also made changes to the script include but whenever I log the secondApprover value it is empty or doesn't appear in the request output). Any help would be great. 

1 ACCEPTED SOLUTION

@Padraig O_Kane1:  Ah, looking closely at your screenshots, a few small variable reference mismatches could be quietly breaking the chain! In your parent client script, c.onRecordChange is trying to broadcast $scope.data.secondApprover, but your <sn-record-picker> actually writes to c.secondApprover (and you'll want to send c.secondApprover.value over). Then, over on the child side, $scope.$on is receiving that payload and setting c.data.secondApprover to the entire event object (obj) instead of obj.secondApprover. Finally, in your child server script , data.secondApprover isn't defined yet on the server, so you'll want to grab input.request.secondApprover directly. If you clean up those three variable assignments, that value should flow right on through to your backend process! You can try the following:

  • Update Parent Client Script: Broadcast c.secondApprover.

  • Update Child Client Script: Set c.data.secondApprover = obj.secondApprover.

  • Update Child Server Script: Use input.request.secondApprover instead of data.secondApprover.

 

View solution in original post

10 REPLIES 10

Padraig O_Kane1
Tera Contributor

Thanks @KPNow , still no output after making a few changes to call rootScope. I'm assuming with the parent widget, all I need to do is configure the new field in the HTML, initialize data.secondApprover = '' in the Server Script and then use $rootScope.$broadcast('secondApprover-data-updated', { secondApprover: $scope.data.secondApprover }); to pass it over to the child widget? I don't need to update the parent widget's updateApproval function (see below)?

 

$scope.updateApprovalRecord = function(state) {
$scope.data.state = state;
if ($scope.data.state == REJECTEDSTATE)
$scope.data.reject = true;
$scope.data.action = APPROVALACTION;
$scope.data.request = {
approvalId: c.data.approvalId,
state: c.data.state,
comments: c.data.comments,
};

No, don't think you need to update the parent's updateApprovalRecord function if the approval action buttons reside in the embedded child widget and fire sendUpdateRequest from there.

Your overall setup on the parent widget is spot-on, with perhaps two small details to double-check:

  1. Parent HTML / Watcher: Ensure your HTML input uses ng-model="data.secondApprover" and calls a function or $watch that fires $rootScope.$broadcast('secondApprover-data-updated', { secondApprover: $scope.data.secondApprover }) whenever the selection changes.

  2. Child Event Name: Make sure the child's listener uses the exact same string ('secondApprover-data-updated') and sets c.data.secondApprover = data.secondApprover.

If you've verified the event name matches and sendUpdateRequest includes secondApprover: c.data.secondApprover, open your child widget's Server Script. Check if it explicitly extracts input.request.secondApprover and passes it to your Script Include; that is most of the time where the chain breaks.

Padraig O_Kane1
Tera Contributor

Thanks  , I introduced ng-model and an on-change function but still don't see the desired output. Please see my screenshots attached where I have highlighted the changes I've made (or at least those that are relevant to this piece). If you can take a look and see if there's anything I've missed, really appreciate your help with this. I feel like I'm not too far off...and need to do some additional Portal Scripting classes 🙂

@Padraig O_Kane1:  Ah, looking closely at your screenshots, a few small variable reference mismatches could be quietly breaking the chain! In your parent client script, c.onRecordChange is trying to broadcast $scope.data.secondApprover, but your <sn-record-picker> actually writes to c.secondApprover (and you'll want to send c.secondApprover.value over). Then, over on the child side, $scope.$on is receiving that payload and setting c.data.secondApprover to the entire event object (obj) instead of obj.secondApprover. Finally, in your child server script , data.secondApprover isn't defined yet on the server, so you'll want to grab input.request.secondApprover directly. If you clean up those three variable assignments, that value should flow right on through to your backend process! You can try the following:

  • Update Parent Client Script: Broadcast c.secondApprover.

  • Update Child Client Script: Set c.data.secondApprover = obj.secondApprover.

  • Update Child Server Script: Use input.request.secondApprover instead of data.secondApprover.

 

Padraig O_Kane1
Tera Contributor

Thanks @KPNow, finally figured out following a few of the updates you suggested that my client controller function to generate the broadcast was in the wrong position, I moved it up and can now see the value being pushed to the approval record. Thanks for your help with this, really appreciate it.