INC-176952 · Issue 660482
DateTime format check added for REST response
Resolved in Pega Version 8.6.2
While retrieving case details using the standard GetCases API, a datetime field defined on a work object was returned in JSON date format i.e. "QuoteExpiryDate": "2021-06-09T14:00:00.000Z". However when the same field was mapped to a flow action's section, the value was retrieved by the GetAssignmentAction API which returned the value in Pega's date format, "value": "20210609T140000.000 GMT". This was traced to a missed datetime format check in the REST response, and has been resolved by using the Rule-Utility-Function pzAPICreateJsonForField to handle the conversion of the time stamp to JSON format.
INC-179217 · Issue 662328
Re-save case type completes successfully
Resolved in Pega Version 8.6.2
Checking in a case type rule with Stage Rule reference was failing. This was traced to the RuleCheckin activity being called in a nested fashion that caused an inner run to remove the "pyOriginalRecord" page which was needed in the outer run to set the .pyRuleset property (at Step 34), and has been resolved.
INC-182332 · Issue 668691
Updated handling for DepStatusFromQueue parameter in CaseDependency
Resolved in Pega Version 8.6.2
The pyCaseDependency declare trigger was not considering the DepStatusFromQueue parameter when an agent was involved. This was a missed use case for a customized calling of the check flow dependency, and was traced to the "DepStatusFromQueue" parameter being empty. This caused the dependency to not be resolved so the parent case was waiting indefinitely even though the child case had reached the required status for resolution, and the system has been updated to handle this scenario.
INC-182776 · Issue 666940
CheckFlowDependencies updated for auto-instantiated child cases
Resolved in Pega Version 8.6.2
A parent case with more than one child case was producing an unexpected behavior during the child case creation process. The first child case was instantiated at the correct point of the case stage based on its dependency condition, but the following cases were instantiated at the same point where the first child case was created irrespective of the dependency conditions defined in the other child cases. Investigation showed that the pxCheckFlowDependencies activity called from the Resolve activity was removing the named pages "pyTopCaseMap" "pyTopCaseWork" which are required for starting and validating configured auto-instantiate child cases in the pzCanStart function. To resolve this, an update has been made to CheckFlowDependencies which will use the activity "pzResolveCaseHierarchyMap" for removing the "pyTopCaseMap" and "pyTopCaseWork" pages based on DependencyType.
INC-183751 · Issue 665892
Improved text contrast for Attach Content button
Resolved in Pega Version 8.6.2
In order to improve accessibility, the contrast between text and background colors has been increased for the Attach Content button by updating pzMultiDragDropControlStandard to change the color from gray to black in function pzInitHTML5DD().
INC-184271 · Issue 668412
Portal Header persists appropriately
Resolved in Pega Version 8.6.2
The Portal header was disappearing immediately after case attachments were opened from the right sidebar and did not reappear even after refresh. This was traced to the absence of pd(event), and has been resolved by adding pd(event) to the onclick attribute in the anchor tag in the attachment UIKit rules.
INC-184300 · Issue 666156
Deprecated status removed from StartCaseType
Resolved in Pega Version 8.6.2
After updating from Pega v8.4 to v8.6, guardrail warnings were seen for the deprecated pxStartCaseType flow rule. This occurred for old case types created prior to v8.5. A utility has already been provided to upgrade the case type to include create stage, but this warning has been resolved by removing the deprecated status on pxStartCaseType to allow processes to proceed without a guardrail warning.
INC-186654 · Issue 669114
GetStatusChanges performance improvements
Resolved in Pega Version 8.6.2
Performance issues were seen when running the GetStatusChanges report. This was traced to the filtering methods used, and has been resolved by updating the report definition and enhancing the filtering conditions.