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-142930 · Issue 600769

Email history will be stripped from case replies

Resolved in Pega Version 8.5.2

When sending an email reply to a case, the entire email history (all previous emails in the email chain) was attached to the case as part of the reply.To resolve this, updates have been made so the system will strip history only when it's a follow-up mail. In addition, an issue with duplicate attachments has been corrected, and attachments from trailing mail will not be copied to a new post.

INC-143320 · Issue 602279

Support added for email addresses with hyphen in domain name

Resolved in Pega Version 8.5.2

When attempting to enter a email with a hyphen '-' in the domain part of an email ID ([email protected]), the reply button was getting disabled. This was caused by the regex validation implemented in the "pzValidateEmailAddress" (Work-Channel-Triage-Email) standard activity not covering all the possible cases. To resolve this, regex has been changed to instead use a platform-provided rule to ValidateEmailAddress.

INC-145425 · Issue 600773

New email template added to include full message history

Resolved in Pega Version 8.5.2

Whenever a reply was sent from the email triage case, the outbound email sent only the actual reply along with the original email and latest reply only, skipping all remaining replies from email. For example, if there were 5 replies from case, replying 5th time generated an outbound email that contained only 5th reply (actual / current), original reply (which created the service case) and the latest reply (reply 4 in this case) and skipped reply 1 and reply 2. To resolve this, a new Outlook-style template has been added for use in replies that will include all of the previous exchanges.

INC-146544 · Issue 604493

Updated handling for unexpected character set in non-UTF-8 email

Resolved in Pega Version 8.5.2

After upgrade, the listener properly created a case from an email, but the space character was being replaced by ? in the inbound emails. Investigation showed the messages did not appear properly in the UI if the email was sent using any encoding other than Unicode (UTF-8) and it had a special character set. To resolve this, the system will remove the attachment type which includes the charset.

INC-150367 · Issue 606028

Double quotes escaped in entity mapping

Resolved in Pega Version 8.5.2

A usecase where the BOTS created the triage cases from the emails and pushed it to the Workgroup had an intermittent problem where the screen would freeze and no actions could be performed. perform any action on the same. Investigation showed this occurred when the entity text contained double quotes which is caused JSON to break on the client side. This generated an exception during rendering, and other onload scripts failed on load and blocked the entire thread. To resolve this, the system will now avoid the JSON break by escaping double quotes in entity mapping.

INC-122112 · Issue 599793

Updated SLA table clearance

Resolved in Pega Version 8.5.2

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-125633 · Issue 589577

Oracle performance improvement

Resolved in Pega Version 8.5.2

Poor performance was seen when importing a RAP with schemas using Oracle. To resolve this, an update has been made which will set the Oracle tuning parameter at the session level by altering the setting "_OPTIMIZER_PUSH_PRED_COST_BASED"=false before the SMA query involving all_constraints. The setting will be returned to true after the execution of the SMA query. This is controlled through the prconfig setting '"database/performance/smaqueryperformanceenabled" which defaults to true so the setting and unsetting of the Oracle parameter is automatic.

INC-125972 · Issue 604080

Improved resolved rules cache

Resolved in Pega Version 8.5.2

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-127420 · Issue 568439

Requestor details shown in Pr_perf_stats table

Resolved in Pega Version 8.5.2

When using a Custom table with the requestor details inserted in the ApplicationSetup activity, comparing the passivated requestors from standard table Pr_perf_stats showed that sometimes requestor details were not present in table Pr_perf_stats. This was traced to the the column value for standard table being greater than the column value for the columns pxDecryptCount, pxDecryptCPU, pxDecryptElapsed, pxEncryptElapsed, pxEncryptCPU, and pxEncryptCount. Database numeric column size is (9,6) whereas other numeric columns have size (18,6). To resolve this, the table scripts have been modified to increase the column size from (9,6) to (18,6).

INC-128800 · Issue 592822

Additional DSS added to handle Apache client-level timeout

Resolved in Pega Version 8.5.2

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, and 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 and 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. is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us