INC-212896 · Issue 711188
Resume Flow will print Flow Action Label in audit history
Resolved in Pega Version 8.6.4
After calling Resume Flow for processing the assignments, when the Assignment was processed the Flow Action Name was printed on the Audit History instead of Flow Action Label. Investigation showed that in the Complete assignment activity, there was no code in the 'if' loop to set the value of actionLabel. If the value was null, the property set in the next step sets actionLabel to flowActionID and the audit history result is FlowAction ID instead of FlowAction Label. To resolve this, logic has been added in the CompleteAssignment Activity step 5 to set ActionLabel with Flow Action Label.
INC-202480 · Issue 699082
Resolved report filter section freeze
Resolved in Pega Version 8.6.4
When opening a report with a count column, changing the order of one of the report columns resulted in the report freezing and requiring the report to be closed and re-run. This was traced to a double filter popup appearing that did not close after the column sorting, which happened if the report definition was configured as a summary with an aggregated column such as "Count” combined with a "Do not display group headings" setting on the Report Viewer tab. To resolve this, a new step has been added in the Activity pzPopulateSortOrder to call the pzCancelFilterLogicChanges activity.
INC-198725 · Issue 707482
Elasticsearch will split queries to avoid URL length limits
Resolved in Pega Version 8.6.4
Elastic Search Functionality was not working and showed the status as Offline. Investigation showed that when an external Elasticsearch setup had an index prefix length = 200 and a large number of dedicated indexes, the error "too_long_frame_exception, reason: An HTTP line is larger than 4096 bytes" was generated. In this case, the system was working with approximately 87 dedicated indexes and the name for each of them was sent over the URL, resulting in this error message. This has been resolved by updating the system to split queries so as to not exceed the HTTP line limit in Elasticsearch.
INC-216358 · Issue 712230
Auto Complete working in Mobile Browser configuration
Resolved in Pega Version 8.6.4
Autocomplete was not working in the mobile browser when logged in as a user and configured with display mode:"in-a-table" and "display as full screen in mobile" disabled. Autocomplete results will always display in List mode in the mobile browser, but with the configuration "in a table" selected and "Display results full screen on phone" unchecked, pzGetACData (which gets called for List mode) was not registered and returned a 403 response. To handle this, the conditions file ActionAssembly.java has been removed so pzGetACData will always be registered.
INC-211251 · Issue 706539
Handling added for Model level Data type empty values
Resolved in Pega Version 8.6.4
After update, the Email Intelligent Virtual Assistant™ (IVA) was not able find the proper response for the real-time incoming emails but was able to find the topic and response when running it from Dev Studio and Prediction Studio. This was due to an edge case where the model datatype page list property was present on the text analyzer rule and a page was present in it, but the property pyName which actually holds the data type (body, attachment, all) was not present in the page. This has been resolved by updating the system to add 'all' as the datatype if the pyName is blank (null or empty).
INC-212704 · Issue 707115
Explicit lock release added for Cassandra threads
Resolved in Pega Version 8.6.4
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-210346 · Issue 709710
Check added to ensure Job scheduler executed only once
Resolved in Pega Version 8.6.4
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-194180 · Issue 704638
GetChildcases handling updated for large numbers of cases
Resolved in Pega Version 8.6.4
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-194415 · Issue 692825
Improvements for dirty popup
Resolved in Pega Version 8.6.4
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 711278
Improvements for dirty popup
Resolved in Pega Version 8.6.4
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.