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.

INC-142589 · Issue 595489

Corrected tooltip evaluation for multiselect

Resolved in Pega Version 8.4.3

After adding help text for a multiselect help icon with overlay on hover field, the value was not being sourced. Changing to a different type of help text or control type worked as expected. This was due to an error in case sensitivity, using pyToolTip when it should have been pyTooltip, and has been corrected.

INC-142714 · Issue 596554

Recent Cases from different applications available to open

Resolved in Pega Version 8.4.3

An enhancement has been added which will allow opening other application assignments in the Recent Cases section of the current application when the user has access to multiple applications.

INC-143005 · Issue 596954

Fluid Overlay displays as expected in Firefox

Resolved in Pega Version 8.4.3

After upgrade, using the Overlay format "Fluid" to perform the screening matches task in CLM using Firefox had an overlay that covered the entire screen but was missing the scrollbar to manage the content. This has been resolved by adding changes to support dynamic content (with scrollbar) for center overlay.

INC-107737 · Issue 544662

Oracle handling updated for upgrade DDL

Resolved in Pega Version 8.6

DDL generated for a Pega upgrade displayed the error "ALTER TABLE PC_ASSIGN_WORKBASKET DROP CONSTRAINT GETNEXTWORKINWORKGROUP" when trying to install. This was traced to a change made by Oracle for optimization, and has been resolved by updating the handling for primary key constraint and the corresponding index name.

INC-121480 · Issue 595823

EnableRedirects property added for REST connections

Resolved in Pega Version 8.6

When implementing a connector with the header “Location” which contains a redirect URI, a 303 response code was expected. Instead, a 400 or 404 error was generated. It was not possible for developers to process the code per their logic in Activity as Connect REST processed 303 responses automatically - i.e. there was no intercept points to implement the suggested approach. To resolve this, the new property "Rule-Connect-REST.pyEnableRedirects" has been added along with a checkbox for the property in "Rule-Connect-REST.pyService" in "Connection" section. Logic has been added in RESTConnector.java to take value of this property and set it on the HTTPClient being used, and a method has been added to HTTPClient interface and ComponentsHTTPClient to use the new value being passed. The default behavior is the same for the REST Connector, but a client can uncheck a checkbox on the REST Connector ruleform to stop the HTTP client from automatically following any compatible 3xx responses.

INC-122112 · Issue 599792

Updated SLA table clearance

Resolved in Pega Version 8.6

After cases were resolved, SLA entries were not getting cleared from the SLA table. This caused the SLA table to have a huge number of Overall SLA and PendFlow details present for cases that were resolved or moved to the next state, which impacted case processing via SLA Agent. This was traced to SLA queue-items not being removed by delete-deferred as expected, and has been resolved by invalidating the deferred operations and scheduling item removal.

INC-125258 · Issue 601606

Documentation updated for troubleshooting rules counts

Resolved in Pega Version 8.6

The troubleshooting documentation has been updated with extended information regarding correcting incorrect rule counts in dashboards and reports.https://community.pega.com/knowledgebase/articles/pega-platform-troubleshooting/troubleshooting-incorrect-count-rules-dashboards-and-reports

INC-125633 · Issue 589578

Optimizing helper class enhanced to handle external databases

Resolved in Pega Version 8.6

Running a BIX extract that included a manifest for a target database was resulting in a null pointer exception for the manifest extraction. Attempting to generate the DDL for the manifest table also failed. This was traced to an issue with the helper class using a hardcoded default database for forming the queries, causing it to ignore the database config/DADN/prconfig for the Oracle database and form a query using the PegaRules' database credentials. This only occurred when trying to do external database operations on a different database platform; Oracle PegaRules worked as expected with an Oracle external database and Postgres Pegarules worked with a Postgres external database, but mixing Postgres PegaRules and an Oracle external database would result in the null pointer exception. To resolve this, the helper class has been enhanced to work with external databases by passing the database name as a parameter so it will properly calculate the query based on the type of target. An error in the name of the class has also been corrected, and is now available as PerformanceHelper rather than the previous "PerformaneHelper".

INC-125972 · Issue 604081

Improved resolved rules cache

Resolved in Pega Version 8.6

When Rule resolution iterated over a candidate list to fetch a candidate, performance issues were seen on very large sites. To resolve this, an enhancement has been added that will cache the resolved virtual table entries to optimize performance in high demand use cases like DSM.

INC-128800 · Issue 592823

Additional DSS added to handle Apache client-level timeout

Resolved in Pega Version 8.6

In Connector rule, the system timed out a connection after 1 hour even after a connection time timeout was configured to be 30 seconds. Apache's refactoring of their HTTPClient in version 4.3 specifies request timeouts in two ways: on the client-level and on the request-level. Client-level timeouts are enforced prior to and during the handshake, whereas request-level timeouts are enforced after the handshake has been made. Previously, RESTConnector.java and ComponentsHTTPClient.java were configured to only set the user-specified timeout on the request, and not on the client. This caused the client-level timeout to default to "0", or an infinite amount of time. In this reported issue, the remote host closed the connection before the handshake had been completed so the connection remained open for several hours. To resolve this, the DSS "ClientLevelHTTPTimeout" has been added to allow specifying a client-level socket timeout, and ComponentsHTTPClient.java and RESTConnector.java have been amended to assign this value to the client. This DSS is set to 0 by default to preserve backwards compatibility.

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