Skip to main content

Resolved Issues

View the resolved issues for a specific Platform release.

Go to download resolved issues by patch release.

Browse release notes for a selected Pega Version.

NOTE: Enter just the Case ID number (SR or INC) in order to find the associated Support Request.

Please note: beginning with the Pega Platform 8.7.4 Patch, the Resolved Issues have moved to the Support Center.

SR-D33934 · Issue 503334

Parent case lock properly released when child case is resolved

Resolved in Pega Version 8.3.1

After creating Parent-Child casetypes with default locking where the child case had the “Allow access to parent” check box checked, the temporary lock acquired on the parent during resolution of the child case was not released afterwards. If “Allow access to parent” was not checked, then the locks were released on both the parent and the child. This was traced to a combination of parameters used by the openIfStale() API where aUnlockOnCommit could be set to false despite the provided locking strategy expecting it to be true, as well as honoring UnlockOnCommit when maintainLockingStrategy is false. To resolve this, the system has been updated to always check whether the lock is available in the map already and if it is, then set unlockonCommit to true. Otherwise, under all cases, honor the passed-in unlockOnCommit value.

SR-D37945 · Issue 506798

Server node cache refresh will use remote execution timeout

Resolved in Pega Version 8.3.1

A campaign was failing due to VBD remote ping timeout with a stacktrace that indicated a StageException. Investigation showed that when the cluster is heavily loaded, calls to the remote execution API could time out. If this occurred when the VBD client was refreshing its cache of VBD server nodes, then the insert failed and the error was propagated up the calling data flow. To resolve this, the system will use the remote execution timeout when refreshing node cache, extend the timeout to 60 seconds, and ensure timeouts are retried during inserts.

SR-D42159 · Issue 508939

Large report pagination should use "Previous and Next only"

Resolved in Pega Version 8.3.1

Some Report Definitions were getting timed out or facing gateway exceptions, primarily due to high time consumed by the DB Queries. Investigation showed the total result count process appeared to stop at the configured pyMaxRecords value as long as it was nonzero. This indicated the issue was related to changes made to fix the inaccurate behavior of the "Last" button in the responsive paginator which included removing logic that set pyMaxRecords to anything other than zero. To resolve this issue, those pagination changes have been reverted. The "Last" button should not be used when the paging mode is set to Numeric: in the case of large reports, the paging option should be set to "Previous and Next only".

INC-162122 · Issue 633067

Create modal is accessible when creating case from Create menu

Resolved in Pega Version 8.6

After creating a new case in the Cosmos User Portal, the “Create” screen Modal Dialog opened but focus did not move to any element within the modal dialog but instead stayed on the “Create” button on the left side menu of the User Portal. It required approximately 50 tabs to reach any actionable element within the modal dialog. Investigation showed that the create modal launched the section in an AJAX container that looked like a modal, but the focus was not being correctly set on the first element. This has been resolved by ensuring there is a focusable element when launching an AJAX container.

SR-D36372 · Issue 504745

Force order added to inner join when running a Rules Resolution filter

Resolved in Pega Version 8.3.1

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-D42645 · Issue 510576

Force order added to inner join when running a Rules Resolution filter

Resolved in Pega Version 8.3.1

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-D42670 · Issue 510182

Force order added to inner join when running a Rules Resolution filter

Resolved in Pega Version 8.3.1

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-139085 · Issue 589553

Documentation updated for using Custom Stored Procedure after upgrade

Resolved in Pega Version 8.6

Documentation has been updated to reflect that when upgrading an environment to Pega 8.3+, the following two prconfig/DSS settings should be removed. This is the preferred approach to use the new ID generation mechanism. Additionally, if a database sequence was previously used to generate IDs, pc_data_uniqueid should be added or updated to make sure each case type has a row defined, and that the pyLastReservedID matches the maximum of the relative database sequence value plus 1. env name="pega/sequenceid/useOldOOTBIDGenerator" value="true" or DSS: prconfig/pega/sequenceid/useoldootbidgenerator/default env name="database/databases/customUniqueIDproc" value="sppc_data_uniqueid_custom" or DSS: prconfig/database/databases/customuniqueidproc/default To keep using the old custom stored procedure, the following settings should be given either through prconfig or DSS setting (prefixed with "prconfig/"). The sppc_data_uniqueid_custom can be replaced with a custom procedure name with the same signature as the standard stored procedure. env name="pega/sequenceid/useOldOOTBIDGenerator" value="true" env name="database/databases/customUniqueIDproc" value="sppc_data_uniqueid_custom"

INC-150325 · Issue 616993

Child case has correct context when created from smart shape

Resolved in Pega Version 8.6

The Cosmos Summary Panel was not always updating as expected when a child case was created via a smart shape in the current case flow; the new case opened, but the summary panel still showed the details of the previous case. This occurred when using a create case smart shape in a flow where the case is assigned to the current user, and was due to the child case assignment being opened inside the parent context. This has been resolved by ensuring the child case is opened in the correct context.

SR-D32525 · Issue 505466

Dirty check added to offer save/discard changes when closing tab

Resolved in Pega Version 8.3.1

With the out-of-the-box 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.

We'd prefer it if you saw us at our best.

Pega.com is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us