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.