INC-212704 · Issue 707114
Explicit lock release added for Cassandra threads
Resolved in Pega Version 8.8
Customer Decision Hub was not responding for realtime request REST service calls, and thread dumps during start up were showing all HTTP request threads were stuck in CassandraSessionCache.getSession. If an error is thrown while invalidating an old Cassandra session, the system may fail to unlock the write lock. This results in subsequent threads being blocked on the session cache's ReadWriteLock when they attempt to retrieve the session from the session cache. To resolve this, an update has been made to ensure that invalidate session is wrapped in a finally block that releases the write lock and log any thrown errors.
INC-194865 · Issue 695620
Corrected report definition save-as-image option
Resolved in Pega Version 8.8
Attempting to save a report definition as an image resulted in an access denied error stating "Browser fingerprint validation failed : A request was received with an invalid or missing browser fingerprint. The request was denied", and the user session was closed. The security SECU0017 alert is generated when a request is sent to a Pega application and the browser fingerprint is either missing or does not match the expected value. The system tries to check the type of request for every requestor ID and fetch the CSRF token, but in this case it was not matching with the token present on the requestor thread. This has been resolved by adding scripts to send the hidden input value needed.
INC-191756 · Issue 718549
Corrected dashboard focus highlighting
Resolved in Pega Version 8.8
Dashboard links like "My activities"/"My cases"/"Recent"/"Search” were displayed with a yellow focus highlight even though the user was not currently in those screens. Investigation showed the data-menu-id for control_menu was being appended with the workid until selecting another tab caused it to reset to its original value without workid. This change in menu-id was responsible for the issue with focus, and occurred only when render as single checkbox was unchecked. This has been resolved by removing workid from menuid and adding a unique id for the outside menu and inside case same menu.
INC-210346 · Issue 709712
Check added to ensure Job scheduler executed only once
Resolved in Pega Version 8.8
When Node A and Node B woke up at the same time to start executing the job scheduler, both were attempting to update the "now processing" node ID with their ID but only Node A succeeded. This caused Node B to generate a "lock already held" exception, then Node B would try to release the lock and update "now processing" node ID. If Node A released the lock before Node B tried to, then Node B updated the "now processing" nodeID and executed the scheduler, causing it to be run twice. This double-run has been resolved by adding a check for whether the job scheduler has been executed recently before starting it.
INC-224548 · Issue 725323
Case Wide Actions do not trigger assignment arrow mark to progress
Resolved in Pega Version 8.8
Given a case type with two assignments in first stage, if the first assignment is completed and then a case-wide action is performed before beginning the second assignment, the the chevron arrow mark was shown pointing to the second assignment even though the user was performing a case-wide action. This was traced to the activity pzLoadStageStatusDP step 10 java step where pxFlow page is taken from the pyWorkPage and the pyLastFlowStep property holds the next step that will be performed. As pxFlow holds the flow parameters of current flow being performed, pxIsCurrent ends up set on the wrong step. To resolve this, a "when" condition has been added in the pyStageStepList section for the arrow mark to be visible only if it is not case-wide local action.
INC-194180 · Issue 704636
GetChildcases handling updated for large numbers of cases
Resolved in Pega Version 8.8
When a very high number of child cases being processed contained a wait shape that was dependent on the movement of a parent case, some of the cases were moved to the next step of the flow automatically while others required a manual command to ResumeFlow. In extreme cases where many child cases were waiting, a node crash could occur. This was traced to the pzGetChildcases report having a maximum value of 500 lines, and has been resolved by increasing the maximum number of rows to retrieve to 9999 in the Data Access Tab of the pzGetChildCases report definition. In addition, the pxCheckFlowDependencies activity has been modified to perform with a higher number of cases, and DSS(MaxRecords) logic has been added to split the child cases into multiple queue items for each access group to decrease load on each thread process.
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.
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.