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.

SR-A87830 · Issue 258092

PD4ML JAR updated

Resolved in Pega Version 7.3

Metadata dates in a PDF generated with PD4ML are expected to follow ISO 8601 format "YYYY-MM-DDThh:mm:ss+##:##", with "+##:##" being the time zone adjustment based on UTC, but when the time zone was given as UTC (or a time zone with zero adjustment), PD4ML was setting the date as "YYYY-MM-DDThh:mm:ssZ00:00". This consequently generated errors with various PDF/A tools. To resolve this, the PD4ml jar has been updated.

SR-A87830 · Issue 259106

PD4ML JAR updated

Resolved in Pega Version 7.3

Metadata dates in a PDF generated with PD4ML are expected to follow ISO 8601 format "YYYY-MM-DDThh:mm:ss+##:##", with "+##:##" being the time zone adjustment based on UTC, but when the time zone was given as UTC (or a time zone with zero adjustment), PD4ML was setting the date as "YYYY-MM-DDThh:mm:ssZ00:00". This consequently generated errors with various PDF/A tools. To resolve this, the PD4ml jar has been updated.

SR-A87830 · Issue 261150

PD4ML JAR updated

Resolved in Pega Version 7.3

Metadata dates in a PDF generated with PD4ML are expected to follow ISO 8601 format "YYYY-MM-DDThh:mm:ss+##:##", with "+##:##" being the time zone adjustment based on UTC, but when the time zone was given as UTC (or a time zone with zero adjustment), PD4ML was setting the date as "YYYY-MM-DDThh:mm:ssZ00:00". This consequently generated errors with various PDF/A tools. To resolve this, the PD4ml jar has been updated.

SR-B40706 · Issue 297501

Unmapped columns from an external table skipped in DDL query generation.

Resolved in Pega Version 7.3

The OBJ-SAVE method was generating a query in which unmapped columns were also getting updated. As these columns were not mapped, DB columns were being updated with the value NULL. This was due to the Obj-Save function always saving the entire object, causing an issue when only part of a table is mapped to a class. To correct this, new prconfig and DASS settings have been added to exclude unmapped columns of an external table as part of DDL query generation.

INC-164532 · Issue 635298

Correct context set for offline chat email processing

Resolved in Pega Version 8.6.1

After configuring "Allow end-customers to submit an email when chat is unavailable", the options for email and message were presented in the chat window and an item was queued for the queue processor cyCreateOfflineEmailMessage, but the queue processor became stuck on the queue item. Investigation traced this to the configuration causing the pyShouldExtensionBeLoaded activity to run under the incorrect context, which prevented it from accessing the needed workparty and goal values. This has been resolved by adding the pyShouldExtensionBeLoaded class to the pages to ensure the correct context.

SR-D48396 · Issue 520424

Hazelcast upgraded to resolve node startup issue

Resolved in Pega Version 8.1.8

Post data upgrade, the ADM tier failed to start and the error "java.lang.IllegalStateException: Node failed to start!" appeared. This was traced to a dormant bug in Hazelcast 3.11 that caused starting nodes to fail when the Hazelcast master node was shutting down, which was exposed by recent Pega changes made to enable parallel restarts of nodes in Cloud environments. Hazelcast delivered a fix for the parallel restart problem and the hotfixed jar has been merged into the platform.

INC-157629 · Issue 626634

Duplicate key exception resolved for adaptive model

Resolved in Pega Version 8.6.1

During the model snapshot update, a DuplicateKeyException was generated while trying to insert a record in to the predictor table. This did not affect the model's learning, but did appear ion the model monitoring report. This was traced to a local scenario of having the same outcome values defined on the model with different cases (Accept and accept). All predictors used in an Adaptive model are inserted into the model monitoring tables as a part of the monitoring job: because the monitoring tables are not case sensitive, this lead to a unique constraint exception since there were multiple IH predictors with the same name. To resolve this, validation has been added which will skip adding duplicates from new responses.

INC-174243 · Issue 655887

Links to specifications persist appropriately

Resolved in Pega Version 8.6.1

When linking Rules to Specifications, check-ins of some unrelated rules deleted the link. Investigation showed the deletion happened in the pzHandleLinksPostCheckIn activity, and was caused by an empty parameter page name that caused pcInsKey to not have a value, so all links returned by "Obj-Browse" were later deleted. To resolve this, an update has been made to insure the "Pass current parameter page" option in step 2 of the Connect REST PostCheckIn activity is enabled so that the downstream activity pzHandleLinksPostCheckIn behaves as expected.

SR-D71522 · Issue 539322

Radio button error resolved for scenario testing

Resolved in Pega Version 8.1.8

When creating a scenario test case that selected a radio button and navigated the screen, it worked to complete a case and save the scenario test case in a rule set. However, attempting to then run the scenario test case stopped with the error message "Value cannot be blank" for the radio button even though the value "No" was captured for the button. This was traced to the firing of the change event, and the system has been updated so 'pega.u.d.setProperty' will only fire a click event on a selected radio button option.

SR-B37115 · Issue 293959

PegaUnits bulk testing updated

Resolved in Pega Version 7.3

AUT test cases were failing while running in bulk, though running a single unit worked as expected. This was found to be a conflict with the way a test case uses a current parameter page from the start of execution to end of execution and then passes it to the next test; if there are two data page test cases where one is configured to have a non-blank value for a given parameter while the second one has a blank value for same parameter, the second test unexpectedly encounters the non-blank value. To resolve this, the code has been modified to reset the value of only RUT params before set up is called, so that every test case behaves truly independently.

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