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.
SR-B54175 · Issue 313627
Complex question Survey collection modified to support pagegroup reference handling
Resolved in Pega Version 7.3.1
Using a valuelist property embedded in a pagegroup to map the response of a Complex question resulted in a clipboard.InvalidReferenceException and the screen did not render the complex question. This was traced to the getMode function on ImmutablePropertyInfo returning the mode for the first property instead of the last property due to the first character being truncated if the property name started with "." To resolve this, SurveyAccessMethodBodyQuestionCollection has been modified to getMode from ClipboardProperty instead of ImmutablePropertyInfo.
SR-B65658 · Issue 294252
New case creation save errors resolved
Resolved in Pega Version 7.3.1
When a new case was created in an application built on top of Pega Pharmacovigilance, data propagation was throwing an error on the screen. Creation worked as expected when the pyDefault case type rule was opened and saved. This issue was traced to the case type rule not being created properly as part of the application creation, and has been resolved by updating pzDoesClassRequireBasicSave to not include Rule-Obj-CaseType in rows so the new application process performs a standard Save instead of an Obj-Save. In addition, it was not possible to save associated rules for selected data type when data type was in a locked ruleset and the pxUpdateRecord API was not setting pyrulename correctly when doing a save-as of the rule; these issues have also been corrected.