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-D39264 · Issue 518840
Multiple files uploaded using "select file" will be handled asynchronously
Resolved in Pega Version 8.2.6
In order to resolve an intermittent error when uploading multiple files using the "select file" button, each file will be uploaded asynchronously to avoid overloading the browser threshold.
SR-D54785 · Issue 524803
Corrected grey area seen when dragging tabbed layout Smartinfo scroll
Resolved in Pega Version 8.2.6
When using Show Smartinfo in a tabbed layout group, a grey area was seen in the harness while scrolling. Scrolling up so that Smartinfo was out of view port caused another scroll bar to seen: one scrollbar was attached to the workarea div and the other to the body, and the gray area issue was only reproducible when explicitly dragging the (second) scrollbar attached to the body. To resolve this, if the popup is below the viewport using Smartinfo and the height calculated is negative, then the popup's height will be set to 0px.
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.
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-D20423 · Issue 503444
Improved upgrade handling for tables using classes with property references
Resolved in Pega Version 8.2.4
After upgrade, some page property values were blank and exposed database columns did not contain the values. Investigation showed that the reference properties did not have context and hence column population was not able to determine their value. To resolve this, instead of doing column population for all the columns, the system will identify classes that have property references and that are being optimized as part of upgrade process and maintain a list of specific columns to update.
SR-D55233 · Issue 520720
AJAX container handling updated to use Harness context API
Resolved in Pega Version 8.2.6
After creating a service case and adding a task to the case, a button configured to refresh the section on a condition worked correctly the first time but did not respond to a second click. This was traced to the tasks being located in two different Ajax containers: in this usecase the condition evaluation logic related to actions was still using the regular DOM API and using the context from the first AJAX container. To resolve this, the system has been updated to use the harness context API pega.ctx.dom.getElementsByName instead of DOM API to resolve the necessary elements from the correct AJAX container.
SR-D54594 · Issue 521634
Enhancement added to customize the clearing of error messages when performing modal actions
Resolved in Pega Version 8.2.6
Opening any modal dialog, for example adding a row in Table/Grid layout, cleared any existing validation error messages on UI screen. In order to make this behavior customizable, a flag has been introduced to control the clearing of error messages from primary pages on grid actions. Updates have been made in the ui_grid, ui_grid_dragdrop and ui_repeatlayout JS files to include this flag in activity parameters and the pzdoGridAction activity has been modified to consider the flag.
SR-D62361 · Issue 534809
Read-Only harness takes precedence over editable section with when condition
Resolved in Pega Version 8.2.6
Given a harness which was marked as Read Only and contained sections which were configured as editable based on some conditions, when the condition became true, the section became editable and ignored the read only conditions applied on the harness. Investigation showed that when a read-only 'when' rule evaluated to false, it rendered the layout in Edit mode instead of falling back to the read-only status of parent. This has been corrected by ensuring that when read-only evaluates to false, the system will fall back to the parent read-only status.