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.

INC-231889 · Issue 736490

Email Parser updated with entity models and datatype casing

Resolved in Pega Version 8.8

When the email bot receives a message, all of the content plus the appended disclosure statement added by the mail server is considered. This was causing issues when words in the disclosure matched words added in the actual email body as keywords, causing the email bot to pickup multiple categories matching these words and not routing the service case appropriately. This has been resolved by adding AnalysisType.ENTITY in the analysisType list for pre-processing models and updating the logic to find out if entity extraction is selected or not (without using the analysisType list). In addition, an issue where pxEmailParser model was not running in the email channel due to an issue with preprocessing model datatype casing has been resolved by updating ExecutePredictionInPRPC to lowercase the datatype after reading from the text analyzer rule page, and then perform the comparison.

SR-C77625 · Issue 415580

Cassandra retry policy enanhancement

Resolved in Pega Version 8.1.3

When configuring the datastax client for Cassandra, it is possible to specify a retry policy. By default the DefaultRetryPolicy is used. While a retry was always attempted on client timeout with this retry policy, a retry on server timeout was only attempted in a limited set of circumstances. This code indicates that for a retry: - The number of received responses is at least the same as the number of required responses - The retry will be done to the same node, not a new node This use makes sense if consistency is set to QUORUM or higher, but it does not make sense for consistency ONE. To resolve this, a new retry policy has been added which will retry in this scenario a configurable number of times. The retry policy and the retry count will be controlled by prconfig settings: prconfig/dnode/cassandra_custom_retry_policy/default - True/False (default: False) prconfig/dnode/cassandra_custom_retry_policy/retryCount/default - >= 0 (default:1)

INC-148657 · Issue 607572

Check added for invalid operatorID set by autopopulate

Resolved in Pega Version 8.4.4

When an SLA rule attached email reminders, the Link-Attachment table saved the creating operator as System. Upon opening the case perform in Cosmos, all attachments were shown in the utility area and the system tried to show the user name using the pyUserDetails linked property, causing the assignment system to generate a "System is not valid operator" error and the case open failed. To resolve this, the system has been updated to avoid setting the error message on Datapage if an invalid operatorid is passed.

INC-228430 · Issue 744988

RUTA handling improved in Prediction Studio

Resolved in Pega Version 8.8

Out of memory errors were seen when using natural language processing (NLP). Investigation showed that certain Apache Rule-based Text Annotation (RUTA) scripts had disjunctive rules which were not able to handle certain types of texts having base64 characters which were introduced in emails via attachments, images, logos etc, and which caused excessive system loads. This has been resolved by modifying the RUTA handling in the Prediction Studio settings to better manage the scenario.

INC-188127 · Issue 678350

Updated cache key generation for ROPC

Resolved in Pega Version 8.8

After configuring outbound email functionality using MSGraph with OAuth 2.0, sending the emails failed consistently following passivation. Running "Test connectivity" in the Email Account data instance then seemed to restart the functionality and the automation "Create And Send Email" subsequently worked. This was traced to a missing username in the cache key generation for the Resource Owner Password Credentials (ROPC), which caused the same token to be fetched when attempting to dynamically generate different usernames, and has been resolved.

INC-211082 · Issue 717175

Updated default portal harness handling for switching applications

Resolved in Pega Version 8.8

After opening the user portal in a new browser tab through interaction with the search, a blank screen was presented when attempting to switch applications via the operator menu. Performing the same actions in the main / originally opened portal worked as expected. This has been resolved by creating a new section pyPortalNavigationHeader in pzPortalNavigation which has an action to open the harness which is available first in D_pzDynamicnavigationpages. This new section has been marked as available to allow local modification of the default harness for sites not using dynamic navigation.

SR-C80050 · Issue 417604

Schema name made consistent for DDL generation

Resolved in Pega Version 8.1.3

A platform upgrade failed if there were application schemas configured with a table configuration that specified a schema other than the rules schema. This was an issue caused by the generated DDL having the incorrect schema name for the table due to the name being hard-coded in the Data-Admin-DB-Table entry definition. The system was using this schema name to find the table and generate the correct changes, but the SQL statement used the table from the database connection instead of the override. When the XML that represents the difference between the "source" and "target" state is generated, the system is supposed to replace the schema name with the target schema name. However, if the source schema name is blank that step was skipped in order to defer to the connection for shipped tables. In order to ensure that the system can generate the correct DDL and complete the upgrade, the system will now always replace the schema name regardless of the source or target value.

INC-125633 · Issue 589575

Oracle performance improvement

Resolved in Pega Version 8.4.4

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-219086 · Issue 724268

Keypair handling updated

Resolved in Pega Version 8.8

Rest API calls were failing with invalid token error in production due to the keypairs used to encrypt the access token being different for each node. This happened when the keypair cache was maintained at node level instead of being retrieved from a database each time; when a keypair expired, a new keypair was created for each node instead of sharing one because the updates to keypair were not properly communicated among the nodes. To resolve this, a check has been added to see if a new keypair is already available in the database before creating a new keypair, handling has been added for any DuplicateKeyException that might occur while saving a keypair to the database, and a pxCreateDateTime has been added while storing the new keypair in the database. Please also note that the default key rotation period is now 180 days and can be adjusted through the setting AccessToken/KeyRotationInterval.

INC-211655 · Issue 712351

Added handling for Malaysian locale date/time

Resolved in Pega Version 8.8

When using the "ms_MY" locale for Malaysia, entering ‘14/02/2022 13:00’ in the displayed DateTime input field generated the error "14/02/2022 13:00 is not a valid date / time value." This was due to differences in the underlying Java version: in Java 8, the API PRDateFormat.getShortDateTimeFormat returns "dd/MM/yyyy h:mm" and the PRDateFormat.getAmPmStrings returns [AM, PM], but in Java 11, the API returns "d/MM/yyyy h:mm a" with PRDateFormat.getAmPmStrings returning [PG, PTG]. For the Malaysian locale ms_MY, the clock format is 12 hour and AM/PM Strings are PG, PTG. This caused environments running JDK11 to fail client side validation for date time when PTG (a 3-char AM/PM string) was selected. This has been resolved by adding handling for this usecase.

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