SR-D33227 · Issue 510824
Check added for lock expiration when using Save for Default locking
Resolved in Pega Version 8.3.1
With the default case locking policy, during the process from creating a Case Object to Submit it was possible for multiple users to edit and save the same work object if the lock expired for the original user. No warnings appeared. To resolve this, handling has been added for a lock expiration scenario: previously, Save for Default locking was not considered. This has now been updated with a check that will evaluate whether or not the lock is gone before attempting to save.
SR-D42456 · Issue 510956
Case status correctly updated when using RDA
Resolved in Pega Version 8.3.1
When a Assignment was routed to a work queue and Flow Action post processing was set to trigger an RDA Automation to update some case property, an error appeared saying there was no data available on the Page and the case status was not updated when it moved to the next stage. This was an issue with case status not being correctly updated when using robotic automation, and has been resolved.
SR-D23906 · Issue 501993
Case status correctly updated when using RDA
Resolved in Pega Version 8.3.1
When a Assignment was routed to a work queue, and Flow Action post processing was set to trigger an RDA Automation to update some case property, an error appeared saying there was no data available on the Page and the case status was not updated when it moved to the next stage. This was an issue with case status not being correctly updated when using robotic automation, and has been resolved.
SR-D21569 · Issue 491702
PUT and WHEN support added for REST
Resolved in Pega Version 8.3.1
Data layer rules in Pega were not getting generated through the Wizard- ‘Create Rest Integration’ when invoking the Rest service though the PUT method. This has been resolved by adding support for PUT and DELETE in pypresentdatapageoptions.
SR-D20817 · Issue 499919
Async cache checking updated for interaction reload use
Resolved in Pega Version 8.3.1
A thread level data page using connect REST to get data from an external system with the "Reload once per interaction" checkbox ticked was being loaded asynchronously from the activity when by default the data page it was supplying needed to be loaded synchronously. Due to this, changes to the data in the external database were not reflected in the data page. This was caused when an async cache was referred and the freshness check for the data page instance did not consider the 'reload once per interaction' flag because it would cause the data page to load twice. The cache checking has been updated to resolve this.
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-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.
SR-D30505 · Issue 501894
Revalidate and save works for Service Packages using OAuth2.0
Resolved in Pega Version 8.3.1
Revalidate and Save was failing for service packages of type Data-Admin-ServicePackage which used authentication type as OAuth2.0 . If this was modified to basic authentication / unchecking authentication, revalidate and save was successful. Historically, the implementation of pzOnlyRestServiceType always assumed the primary page was the Service Package rule itself. To support this alternate use, the logic has been updated and a check of the Service Type has been added for the pxResults of the data page.