SR-B31873 · Issue 298086
Review/Perform harness modifications for scheduled report errors
Resolved in Pega Version 7.3
Scheduled reports would periodically go to Completed state and stop running prematurely. Deleting and then reopening a scheduled report (from recents) caused corruption of scheduled reports that are re-scheduled. This was traced to the Review/Perform harness going in to a corrupt state, and has been corrected by re-building the Review harness as well as some minor changes to the Perform harness to ensure the correct buttons are displayed when deleting a scheduled report and reopening it from the recents list.
SR-B41820 · Issue 299434
Map from field updated to ensure Correspondence Name and Type are included
Resolved in Pega Version 7.3
An error was generated while configuring a Map From field as Correspondence. This was an issue with the Correspondence Name not being passed: when the Map From is selected as Correspondence, the backend expecting the Map from Key as a space separated combination of Correspondence Name and Correspondence Type. If only the Correspondence Name was selected, then the back end failed to find the Correspondence Type. This has been fixed by modifying the code to combine left and right from key part to ensure both parts are sent.
INC-185362 · Issue 668826
Keystore update properly revises the cache
Resolved in Pega Version 8.7
A keystore updated with the latest certificate was not getting reflected in the runtime and the old certificate was getting picked. In a multi-node environment when the new JKS is uploaded in one node, the changes are expected to be communicated to other nodes so that the cache can be cleaned up. In this case, investigation showed that the keystore label was in uppercase and the cache entry was not correctly removed. This has been resolved by adding an update that will convert the cache key to lowercase and maintain uniformity to ensure proper cleanup.
INC-195354 · Issue 682183
Handling updated for UpgradeBeforeOpening
Resolved in Pega Version 8.7
After update, an email case paused for 1 minute with a wait shape and then resumed by a ServiceLevelEvents agent seemed to lose the context (class) of the case and went into the broken processes queue with the error "Unable to open an instance using the given inputs: pxObjClass = "Work-Channel-Triage"". This was traced to an incorrect class applied by the activity OpenAndLockWork which assumed that "Work-Channel-Triage" was the preferred class and passed in the case ID as a parameter. To resolve this, pzUpgradeBeforeOpening has been updated such that it will migrate a case only if it has "WORK-CHANNEL-TRIAGE" in the work object inskey.
SR-A102237 · Issue 271876
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.
SR-A87830 · Issue 258083
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 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.