SR-D42670 · Issue 510183
Force order added to inner join when running a Rules Resolution filter
Resolved in Pega Version 8.2.4
After upgrade, D_getResolvedWorkStatuses was not loading properly due to a Report Definition that used a Filter by Rule Resolution option timing out on the SQL Server. When the Filter by Rule Resolution option is selected in Report Definition, it will generate a rule resolution query with an inner join which can cause a time out on the SQL Server while it tries to find out the join order for tables with multiple joins. To resolve this, the SQL server will provide a Force order, merge inner join hint option by way of an added DSS reporting/useForceOrderHint. Additionally, reporting/useMergeHintForRRquery should be set on Pega-Reporting to set things up for using the Merge Inner join hint in the query.
SR-D36372 · Issue 504746
Force order added to inner join when running a Rules Resolution filter
Resolved in Pega Version 8.2.4
After upgrade, D_getResolvedWorkStatuses was not loading properly due to a Report Definition that used a Filter by Rule Resolution option timing out on the SQL Server. When the Filter by Rule Resolution option is selected in RD, it will generate a rule resolution query with an inner join which can cause a time out on the SQL Server while it tries to find out the join order for tables with multiple joins. To resolve this, the SQL server will provide a Force order, merge inner join hint option by way of an added DSS reporting/useForceOrderHint. Additionally, reporting/useMergeHintForRRquery should be set on Pega-Reporting to set things up for using the Merge Inner join hint in the query.
INC-176757 · Issue 657785
Interaction History properly saved when running strategy on a different data flow
Resolved in Pega Version 8.7
Customized Interaction History properties that had been added to pyInteractionHistoryConfiguration and pyDefaultWorkingSet and saved into the PR_DATA_IH_FACT table were not being saved properly after upgrading from 7.3 to 8.3. This was a missed use case and has been resolved.
SR-D2286 · Issue 439250
UIKit 12 updated to ensure data pages are cleared when switching applications
Resolved in Pega Version 8.3
When using UIKit 12, switching applications without logging off resulted in the 'Recent reports' list and Public Category containing reports and folders that belonged to the previous application. Investigation showed that the pyCMReportBrowserHeader function in UIKit 12 did not include the custom control "pzRBIncludes7", which clears the data pages. This has now been added to ensure that report browser data pages are now automatically cleared on app switch.
SR-D32525 · Issue 505467
Dirty check added to offer save/discard changes when closing tab
Resolved in Pega Version 8.2.4
With the OOTB section enabled, performing a change in the form (changing a text value, selecting a option in a dropdown, etc.) and closing the case generated an unexpected alert indicating that the case was changed and the modifications were lost. This differs from the previous behavior of showing the section pyDirtyCheckConfirm which offered the opportunity to save the work. This was a missed use case and has been resolved by updating the system to perform a check for the dirty state when closing the interaction and show a modal dialog asking the user to choose either save/discard if dirty.
SR-C50284 · Issue 390659
Top level activity steps are numbered correctly when child steps exist
Resolved in Pega Version 8.2
Top level activity steps were showing as being numbered incorrectly when child steps existed, but saving the rule or refreshing the rule corrected the numbering. This was caused by CSS that was added to the rule form harness to increment the step number; while expanding a top level node the reset happened and then the counter initialized the value. To address this, the code has been changed from CSS counter to CSS attr which will use the index attribute of the current row. Additional CSS cleanups were also done to remove IE9 and other browser-specific styling that is no longer needed.
SR-A2141 · Issue 205867
Refined refresh focus logic for radio buttons using on OnChange
Resolved in Pega Version 7.1.9
In a list of Radio Buttons, using the Down Key caused focus to move to the corresponding Radio Button for a split second but immediately shift back to the first Radio Button. This was caused by the OnChange of the radio button having a refresh-this-section, so ReloadSection was being called and the focus was shifted to the first radio button irrespective of the option which was selected. This was confusing behavior, so the system has been modified such that after refresh, focus() element will be called to set focus on the element which caused the refresh.
SR-A2141 · Issue 205271
Refined refresh focus logic for radio buttons using on OnChange
Resolved in Pega Version 7.1.9
In a list of Radio Buttons, using the Down Key caused focus to move to the corresponding Radio Button for a split second but immediately shift back to the first Radio Button. This was caused by the OnChange of the radio button having a refresh-this-section, so ReloadSection was being called and the focus was shifted to the first radio button irrespective of the option which was selected. This was confusing behavior, so the system has been modified such that after refresh, focus() element will be called to set focus on the element which caused the refresh.
INC-154189 · Issue 617247
Harness used to determine read-only for button/text input
Resolved in Pega Version 8.4.4
If a button/text input was configured to always be editable in a section by using the /v1/cases/{ID}/pages/{pageID} API (say i.e PageID as Review), the button/text input was always returned as readonly. This was due to the API being hardcoded to return readonly info, and has been resolved by updating pzGetPageDetails to not force read-only and let the harness configuration decide the behavior.
INC-138840 · Issue 599980
Data-Summary reports default will not use the rule resolved setting
Resolved in Pega Version 8.4.4
An intermittent issue was seen where a query could become stuck for ~2 hours in the database. This has been resolved by setting the default for Data-Summary reports to not use the rule resolved setting.