INC-207218 · Issue 706369
Check added to prevent duplicate approval by single agent
Resolved in Pega Version 8.6.4
When using a cascading Approvals process supported both by a web access button or by responding via email, a single agent could use both methods and advance a case an additional step as if they were the next approval level. This was due to the system only checking the pzInsKey when processing the approval while the assignment key will be the same for the cascading approvals assignments. This has been resolved by introducing a datetime check to validate if the email approval assignment creation datetime and the one in the database have same value; if yes the approval process will proceed and if not it will exit.
INC-207320 · Issue 701082
Email Approver shown in audit
Resolved in Pega Version 8.6.4
Email Approver activity was not being shown in Audit. This was traced to the queue instance primary page missing the necessary pyInboundEmail page property from pyCreateAndManageWorkFromEmail, and has been resolved by updating the listener activity to copy the needed value to a property called pyEmailFrom which will be used to record the events in the audit.
INC-207996 · Issue 709663
Check added for parent case dependency if deferred-save is used
Resolved in Pega Version 8.6.4
After updating the status of a parent case to "Pending-ChildCaseDependency", the wait shape for the child case that should have been triggered by the status did not work and the child case remained on hold. This was a missed use case for the pxCheckFlowDependencies activity where defer-save operations on Index-AssignDeps class was not considered, and may happen when the Queue Processor is evaluating the dependencies while instances to Index-AssignDeps are not committed yet. To resolve this, code has been added to check the entry of the parent case dependency in deferred-save if its not present in Index-AssignmentDeps table.
INC-210680 · Issue 712072
Updated logic for setting param.PrimaryPage in transfer
Resolved in Pega Version 8.6.4
TransferAssignment was failing intermittently when doing routing either by background processing or manual transfer. Investigation showed this was caused by a null param.PrimaryPage value which resulted in a NullStepPage exception. This has been resolved by adding a Property-Set method just before calling the activity pxTransferAssignment. In addition, the "Require authentication to run" check box in the pxTransferAssignment activity has been set to on.
INC-212896 · Issue 711188
Resume Flow will print Flow Action Label in audit history
Resolved in Pega Version 8.6.4
After calling Resume Flow for processing the assignments, when the Assignment was processed the Flow Action Name was printed on the Audit History instead of Flow Action Label. Investigation showed that in the Complete assignment activity, there was no code in the 'if' loop to set the value of actionLabel. If the value was null, the property set in the next step sets actionLabel to flowActionID and the audit history result is FlowAction ID instead of FlowAction Label. To resolve this, logic has been added in the CompleteAssignment Activity step 5 to set ActionLabel with Flow Action Label.
INC-183650 · Issue 678312
Corrected doubled tag removal
Resolved in Pega Version 8.6.4
After adding two tags for a Service case, attempting to delete the first tag resulted in the second tag also being removed. When three tags were present in the case, deleting the first tag caused the first and second to be deleted. Investigation showed this was caused by the run activity pyRemoveTagLink being called twice in run time, and has been resolved by updating the run activity.
INC-135335 · Issue 588510
Parent flow next step will take precedence over sub-process
Resolved in Pega Version 8.5.1
A Breadcrumb configured in the screen flow was not displaying at the last assignment when there were multiple embedded sub processes and the last assignment was called in a sub process. This was traced to the parent flow next step information not being passed due to the next step in the sub process being marked as an end shape. To resolve this, the pzFlowSteps7 html control has been updated to pass the parent flow's next step information in this situation.
SR-D77719 · Issue 569769
OpenIfStale updated to resolve optimistic locking race condition
Resolved in Pega Version 8.5.1
A race condition was created in optimistic locking by having two assignments save at overlapping times. This has been resolved by modifying the pzShowConflicts activity to use a version of openIfStale which will consider a workpage as stale even if the difference in pxUpdateDatetime is in milliseconds.
INC-134912 · Issue 581326
Handling updated for wait shapes with different outgoing connector flow actions
Resolved in Pega Version 8.5.1
After configuring a flow with a wait shape that by default used the pyContinueAfterWait flow action for the outgoing connector of the wait shape refer, adding any other valid flow action resulted in the error "Action To Take must be a valid flow action for this assignment". This was due to the post-processing of the connector properties modal updating the ActionToTake value based on wait shape, so that changing the flow action on a connector caused the validation on save to fail if the ActionToTake on wait shape and the connector flow action did not match. To resolve this, the system has been modified to validate a wait shape with different flow action on the outgoing connector.
SR-D59283 · Issue 523207
Check added for WorkParty property to catch changes
Resolved in Pega Version 8.5.1
After configuring a send email shape to send email to work parties, proceeding through the flow without work parties and then triggering the send email shape and creating the Fix correspondence assignment worked as expected. If the work party details were later updated and the send email shape was triggered again for the Fix correspondence assignment, the error message "No role defined to work object" appeared. This was an issue with the handling of the email flow the second time through: PyCorrPage.pyCorrPartyRole did not have the work object party details which were added to the work object after the fix correspondence assignment was created, and SendSimpleEmail was not designed to handle the email that needs to be retried during the FixCorrespondence flow call. To resolve this, the system will check whether the pyWorkParty property exists prior to calling the PartyCorrPreferences HTML rule.