SR-D37980 · Issue 512436
Data page triggered from SLA reloads per interaction
Resolved in Pega Version 8.4
After configuring an SLA goal activity which takes one parameter from a thread-level data page with 'Reload once per interaction' checked and the source of the datapage was a data transform which used pyWorkPage.pyID to set a property value, goals were not updated as expected. If multiple cases reached their SLA goal at the same time, the first case ID was being sent as a parameter to the goal activity for all of the other case IDs. For example, if case 1, case 2, and case 3 reached their goal at the same time, the case 1 ID was passed as the goal activity parameter to case 2 and case 3. This was traced to multiple items that were getting processed in a single agent run picking up the stale data present in data page because it was not being cleared, and has been resolved by removing the Read-Only data pages after every item that is processed, ensuring that it will be reloaded the next time the data page is triggered.
INC-217855 · Issue 731911
Uncommitted hotfix able to Rollback All after install
Resolved in Pega Version 8.8
A security hotfix was installed through Hotfix manager and left as uncommitted. When new hotfixes for the same files were received, the process required the uncommitted hotfixes to be rolled back, but attempting to do so generated exceptions in the logs reading "Exception in rolling back the archive PegaRULES Process Commander: code: 0 SQLState: Message: java.sql.SQLIntegrityConstraintViolationException: ORA-00001: unique constraint (PRPC_RULE_ADM_P7.PR_ENGINECLASSES_PK) violated". The issue was caused by the Date field only accepting dd/mm/yyyy HH:MI:SS, so attempting to insert two records of the same jar in the pr_engineclass generated this error from pr_data_restore in Oracle. To resolve this, an update has been made to insert rolled-back jar removals with their original patch date to avoid PK conflicts.
INC-225687 · Issue 739708
Handling added to avoid incorrect true value for DateTimeisPastOrFuture
Resolved in Pega Version 8.8
When the Function pxDateTimeisPastOrFuture() was called with the arguments "" (the empty String) and "false", it sometimes returned "true" instead of "false". This function internally calls the Function CompareDates() which takes two Strings as arguments. In this case, one is provided by the caller of pxDateTimeisPastOrFuture, the other one is generated at runtime, as the current date/time. As the second argument of pxDateTimeisPastOrFuture, the generated date/time will be the first parameter, while the second one is the date/time argument for pxDateTimeisPastOrFuture. If that argument is the empty String, is will be replaced by the current date/time. This means that the value for the second parameter is determined after the first parameter and that can result in a gap in time by a few milliseconds. This in turn results in "true" as the return value for pxDateTimeisPastOrFuture. This has been resolved by adding handling for a blank string so "false" is returned correctly.
SR-D42888 · Issue 511452
ElasticSearch startup modified
Resolved in Pega Version 8.4
Search was broken on the app-tier node due to the Full-text search startup failing during a re-initialization. As part of normal re-initialization, the existing node is shut down and the Elastic Search node started. However, in this case because the shutdown process was not properly invoked, the system attempted to start the second instance of an ES node on the same machine. The shutdown process is reliant on a boolean flag which indicates if the current status of the full-text search initialization is successful: this flag indicated initialization had failed when actually the ES node had started but failed to validate all the cluster level settings due to topology changes in the Pega cluster. In order to avoid this scenario, the restart has been split so that the node can be marked as started but not initialized. This allows the follow-up reinitializations a greater opportunity to succeed. In addition, the shutdown FTS code has been modified to shutdown ES regardless of the search initialization status.
INC-196389 · Issue 690786
ConfigurationReconciliationTask updated for greater compatibility
Resolved in Pega Version 8.7
After updating from Pega 8.3 to Pega 8.6, models which previously had learning and performance AUC greater than 0.7 reported an AUC of 0.5. This was traced to the update handling in ConfigurationReconciliationTask. AdmRuleBrowser does not perform ruleset resolution, so all rules were returned, for example the rule for model A in both the 08-01 and 08-03 ruleset. The system then iterated over all of the adaptive model rules returned by AdmRuleBrowser in order to assess whether a configuration update was necessary. The condition to update the model rule was met when either the config key did not exist (indicating a newly added configuration) or the model rule was "old" (version <2). For models generated in Pega 8.3 or earlier the version number for all rules must be 1, and the update to Pega 8.6 therefore caused the ConfigurationReconciliationTask to be applied to all adaptive model rules. To resolve this, the configuration update check in ConfigurationReconciliationTask has been removed.
INC-201335 · Issue 690733
ConfigurationReconciliationTask updated for greater compatibility
Resolved in Pega Version 8.7
After updating from Pega 8.3 to Pega 8.6, models which previously had learning and performance AUC greater than 0.7 reported an AUC of 0.5. This was traced to the update handling in ConfigurationReconciliationTask. AdmRuleBrowser does not perform ruleset resolution, so all rules were returned, for example the rule for model A in both the 08-01 and 08-03 ruleset. The system then iterated over all of the adaptive model rules returned by AdmRuleBrowser in order to assess whether a configuration update was necessary. The condition to update the model rule was met when either the config key did not exist (indicating a newly added configuration) or the model rule was "old" (version <2). For models generated in Pega 8.3 or earlier the version number for all rules must be 1, and the update to Pega 8.6 therefore caused the ConfigurationReconciliationTask to be applied to all adaptive model rules. To resolve this, the configuration update check in ConfigurationReconciliationTask has been removed.
INC-194415 · Issue 710825
Improvements for dirty popup
Resolved in Pega Version 8.8
Multiple issues have been addressed for dirty popups. 1) While working on an assignment, making a change and then clicking on the left navigation (Home, Dashboard) did not show the dirty pop up as expected, and the change was lost. The dirty pop up did appear on the Cancel button and Actions within the case. This has been resolved by improving the context switching for visibility of the dirty pop up. 2) Attempting to work around the previous issue by clicking "Do not display dirty warnings" only worked the first time it was tried. With this change in place, opening the assignment, making a change, then clicking Home, caused the pop up to appear as desired, but opening the assignment again and making a change, then clicking Home again did not prompt the dirty pop up. This was due to the click handler getting hit twice, leading to the already open dirty dialog being closed during the second call to the function 'isFormDirty' in pzpega_ui_doc_actionRouter.js file, and this has been resolved. 3) When attempting to close the case as a draft, clicking the save button caused the system to keep loading for a few minutes without sign of completing the save process and eventually the browser had to be closed. The content was saved, but the system was not able end the loading screen. This was caused by an incorrect harness context which caused the "SubmitInProgress" flag to be true on the incorrect harness context so the modal was not dismissed. To resolve this, on clicking the "Save" button, after the confirmation modal is closed, the pega.u.d.isDirtyDialogOpen will be reset to false.
INC-211253 · Issue 711280
Improvements for dirty popup
Resolved in Pega Version 8.8
Multiple issues have been addressed for dirty popups. 1) While working on an assignment, making a change and then clicking on the left navigation (Home, Dashboard) did not show the dirty pop up as expected, and the change was lost. The dirty pop up did appear on the Cancel button and Actions within the case. This has been resolved by improving the context switching for visibility of the dirty pop up. 2) Attempting to work around the previous issue by clicking "Do not display dirty warnings" only worked the first time it was tried. With this change in place, opening the assignment, making a change, then clicking Home, caused the pop up to appear as desired, but opening the assignment again and making a change, then clicking Home again did not prompt the dirty pop up. This was due to the click handler getting hit twice, leading to the already open dirty dialog being closed during the second call to the function 'isFormDirty' in pzpega_ui_doc_actionRouter.js file, and this has been resolved. 3) When attempting to close the case as a draft, clicking the save button caused the system to keep loading for a few minutes without sign of completing the save process and eventually the browser had to be closed. The content was saved, but the system was not able end the loading screen. This was caused by an incorrect harness context which caused the "SubmitInProgress" flag to be true on the incorrect harness context so the modal was not dismissed. To resolve this, on clicking the "Save" button, after the confirmation modal is closed, the pega.u.d.isDirtyDialogOpen will be reset to false.