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 update your bookmarks. This site will be discontinued in Dec 2024.

Pega Platform Resolved Issues for 8.1 and newer are now available on the Support Center.

SR-D48433 · Issue 529857

Exception handling added for Redirect URL fetched from GRS

Resolved in Pega Version 8.4

When the application definition under “integration and security" tab was configured to use "Store in web storage provider" to allow choosing the storage name and the authentication profile, configuring the authentication profile to use an OpenID connect provider with the pyEndpointURL property given as a global resource setting such as (=D_SharepointDetails.url) was not working as expected. Clicking browse in the application definition sent the request to the OpenID connect provider and was returned with the error "The reference =D_SharepointDetails.url is not valid. Reason: Page name (D_SharepointDetails) from indirect reference was not found." This was traced to the Redirect URL (fetched from GRS) throwing an unhandled exception, and has been resolved.

SR-D48762 · Issue 518299

Enhancement added to support DB2 CREATE OR REPLACE view syntax

Resolved in Pega Version 8.4

After creating the product, attempting to import it on another environment failed due to incompatibilities with the syntax. In SQLGeneratorDb2.getViewSourceStatement(), when the View definition is fetched there is a check whether the view starts with "CREATE VIEW". Since the customer view of "CREATE OR REPLACE" was not supported in Db2LUW, it didn't match and appended the "CREATE VIEW" statement again. This happened only when using DB2, and has been resolved by updating the logic in SQLGeneratorDb2.getViewSourceStatement() to support CREATE OR REPLACE VIEW statements.

SR-D50057 · Issue 521980

Added null check when updating OperatorID activity after passivation

Resolved in Pega Version 8.4

An issue with operators being able to see work outside of their own authorization was traced to an underlying issue with how the sessions were passivated after either inactivity for a long time or closing the browser directly without logging off. Investigation showed the conditions resulted in a null pointer for the operatorpage in the basic flow, and this has been resolved by adding a null check prior to copying the primary page data to the operator ID page as part of updating the operatorID activity.

SR-D50539 · Issue 521150

Database locking improved for login performance

Resolved in Pega Version 8.4

A slowness issue seen when trying to login to my.pega.com was traced to numerous database locks occurring on the pr_data_saml_authreqcontext table during the SAML flow. Analysis showed that while running Obj-Save on AuthRequestContext with 'OnlyIfNew' as false, the check caused a select query to run on the table to determine if the context was already there and insert it if it was not. To resolve this, the onlyIfNew check will default to true to avoid running the query; if the context is already present it will be overridden. Duplicate key exception handling has also been added to avoid any issues if a resave is done with same key.

SR-D51324 · Issue 523435

Authentication state refreshed after failure in mobile

Resolved in Pega Version 8.4

When using the mobile app, if the log in was started and incorrect credentials or empty fields were submitted and then the credentials screen was X-ed out or canceled, attempting to log in again using the correct information still received the "Authentication failed" error. A subsequent attempt with the correct credentials would then work. This was traced to the server persisting the state from the first request (per browser session), and has been resolved.

SR-D52037 · Issue 519479

Added compatibility for generated SQL to be imported to MSSQL from DB2 Z/OS

Resolved in Pega Version 8.4

After creating an application jar which has schema changes on DB2 Z/OS, attempting to import the jar in a different environment that used an MSSQL database failed to execute the schema changes /SQL statements and reported syntax errors. Investigation showed that MSSQL wraps usernames in [square brackets] in GRANT statements generated by import, and support for this has now been added.

SR-D52142 · Issue 517586

pzinskey LIKE clause removed and agent adde clean stale pr_data_token data

Resolved in Pega Version 8.4

In order to improve performance, an agent has been added to clean up expired accessToken data in pr_data_token and the 'where' clause pzinskey LIKE has been removed and replaced with native SQL to support queries in all databases.

SR-D52969 · Issue 514704

Column population honors thread count of 1

Resolved in Pega Version 8.4

The thread count parameter in the column population activity was not being honored, causing repeated deadlocks when trying to populate columns. Investigation showed that the ExposeCols process did not honor the thread count when it was 1 (the default is 4), and this has been fixed by adding the necessary code so that if the thread count is 1, it will not run in multhreaded mode.

SR-D53838 · Issue 521479

Run Ruleset Cleanup defaults to true

Resolved in Pega Version 8.4

After upgrade, the rule categories and rules were not showing correctly in the App view of the Dev Portal. Many warning messages were also logged related to the Decisioning DM Sample application. This was traced to the rules cleanup script not running properly. While there was a workaround of applying the ruleset cleanup scripts manually after removing the queries that reference the pr_engineclasses table, the cleanup will now be set to run by default (run.ruleset.cleanup=true). In addition, the logic to determine which RuleSets to include has been simplified and most of the pr4_rule_vw deletions have been combined.

SR-D55508 · Issue 521862

CSRF and Fingerprint token handling added to custom URL generation

Resolved in Pega Version 8.4

An error screen appeared with the message "Server response error, no update data returned" while doing a check out and check in of the offer rule. This was traced to CSRF token validation: in this scenario, a custom URL was being framed and the corresponding request did not have a valid CSRF/ Fingerprint token, which can occur when there are custom AJAX/Non-ajax URLs constructed manually in the non-autogenerated/HTML streams. To address this, handling has been added for CSRF and fingerprint tokens as part of the custom URL generation.

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