SR-B53918 · Issue 312285
Optimistic locking on resolved case fixed for Back button use
Resolved in Pega Version 7.3.1
It was possible to perform an action on a resolved case when in screen flow, i.e. when in the middle of a screenflow of a case and the case gets resolved due to some action in another case. If Refresh was clicked from the Actions, the case was updated as Resolved-, but clicking on the Back button of the screen flow ignored the Resolved status and allowed changes to be made. The logic to check for stale data (optimistic locking) was missing on the Back button in the screen flow, and has been fixed.
SR-B51521 · Issue 310823
Null Pointer Exceptions resolved for Null Pointer Exceptions in pzBulkProcessingList HTML
Resolved in Pega Version 7.3.1
Null Pointer Exceptions were being generated in pzBulkProcessingList HTML while working with bulk processing. When trying to reopen a work object through bulk processing by calling Reopen activity, the Work object was successfully reopened and committed but some parameters were lost while loading the harness. Null checks have been added to pzBulkProcessingList handle the issue and avoid the Null Pointer Exceptions.
SR-B55777 · Issue 313143
Bulk processing out-of-the-box filter conditions correctly displays all records
Resolved in Pega Version 7.3.1
On launching the bulk actions in manager portal, records are displayed based on the filter properties - CaseType, AssignedToOperator & WorkStatus. However, on deleting and adding the last filter 'WorkStatus' and clicking on filter cases, records were removed from the UI. This was traced to pyUserIdentifier and pyLabel being cleared on a step of 'pzDefaultOperators', resulting in incorrect SQL query generation and no records retrieved from the database. This has been fixed by deleting the erroneous removal step for this function. In addition, it was noted that the activity 'pyPreBulkProcessing' gave the default value for the Assigned To Operator property filter value as "OperatorID.pyUserName" (set in double quotes); this caused the filter value of AssignedToOperator to be set to 'OperatorID.pyUserName' in the clipboard irrespective of user selection. The enclosing double quotes have been removed so the parameter will be correctly set.
SR-B52699 · Issue 313633
Checks added to optimistic locking to ensure correct assignments for multiple flow users
Resolved in Pega Version 7.3.1
On refresh of a processed assignment in an optimistic lock scenario, a new assignment created in the background by a different user in the same flow was picked instead of the expected result of the review screen for the processed assignment. This was an issue where the pxAssignmentKey and pxFlow name were being reused without being properly differentiated. To correct this, the pxCreateDateTime parameter will also be used to determine the correct assignment if it gets created from same flow along with checks for RefreshOnConflicts activity and pxTimeFlowStarted.
SR-B31405 · Issue 306582
XSLTranslate security checks reverted
Resolved in Pega Version 7.3.1
Security checks recently added to the XSLTranslate activity were causing compiling problems. The security checks have been removed at this time.
SR-B41316 · Issue 306255
Resolved missed cases in the WO case tree
Resolved in Pega Version 7.3.1
Sometimes several cases were missed in the case tree, shown in the right side of an opened WO. Access was not available for the corresponding WO and assignments. The root cause was a WHEN condition in WORK-COVER- PZLOADNESTEDCASESFORCLASS property "local.ProcessedItemKeys" containing numbers of processed WOs separated by a space, for example, "KPI-101 KPI-72 KPI-52". The WHEN condition checks for presence using "contains", leading "KPI-10" to be ignored and not displayed in cases where "KPI-101" already presented. To correct this, the system will consider the delimiter "\t" while checking the WHEN condition.
SR-B41316 · Issue 306260
Resolved missed cases in the WO case tree
Resolved in Pega Version 7.3.1
Sometimes several cases were missed in the case tree, shown in the right side of an opened WO. Access was not available for the corresponding WO and assignments. The root cause was a WHEN condition in WORK-COVER- PZLOADNESTEDCASESFORCLASS property "local.ProcessedItemKeys" containing numbers of processed WOs separated by a space, for example, "KPI-101 KPI-72 KPI-52". The WHEN condition checks for presence using "contains", leading "KPI-10" to be ignored and not displayed in cases where "KPI-101" already presented. To correct this, the system will consider the delimiter "\t" while checking the WHEN condition.
SR-B53650 · Issue 310574
Handling added to AssignmentListGadget for missing required properties
Resolved in Pega Version 7.3.1
The first step of pyPopulateCaseContents has multiple "break" statements in it. If any of those break statements were executed (such as due to a missing property) and resulted in "missingRequiredProperties" being set to true, the display of the gadget became broken. This was related to missing leading icons when a property doesn't exist, and pyPopulateCaseContents has been updated to resolve this issue.
SR-B52942 · Issue 311092
ResumeFlow modified to ensure all activity params show in SLA rule form
Resolved in Pega Version 7.3.1
The full list of activity parameters in the SLA rule form were not visible if the ResumeFlow activity had parameters called 'flowName' or 'calledFromServiceLevel'. This issue was caused by missing handling for parameters that are given but not needed. The ResumeFlow API has three parameters: 'flowAction', 'flowName', and 'calledFromServiceLevel'. Of these three, the value for 'flowAction' needs to be provided in this use. The other two parameters do not, as the runtime facility passes them through and they do not need to be set. To handle this scenario, logic has been added to skip these parameters for the ResumeFlow activity.
SR-B55376 · Issue 313068
Mandatory field highlighting fixed for attachment window
Resolved in Pega Version 7.3.1
The mandatory field highlighter (asterisk) was not getting displayed for " Window Name" and "Note" in the Attach A Screen Shot window. This was due to a handling error for an accessibility check, and has been fixed.