SR-D90331 · Issue 553607
Context-specific APIs used for RefreshHarness with AJAX container
Resolved in Pega Version 8.2.7
After creating an interaction case and letting it go idle, attempting to continue and process the service cases in that case was intermittently resulting in a transaction ID mismatch error. This was traced to handling in the AJAX container, and has been resolved by updating the system to use context-specific APIs for refreshHarness case in doc_submit.
SR-D91964 · Issue 551091
Negative values in optimized table filters show markup
Resolved in Pega Version 8.2.7
HTML markup was shown in the filter popup when Number control was used in a Table cell and there were negative values in the cells at runtime. This was traced to work done on template grid filtering, and has been corrected.
SR-D92571 · Issue 553114
Corrected ReportBrowser refresh section
Resolved in Pega Version 8.2.7
After bringing up the popup menu on a report shortcut in the report viewer and then dismissing it, the gear icon on the shortcuts in the upper section of the report browser stopped responding. This has been resolved by updating the system to refresh the pyReportBrowserInner section instead of pyReportBrowserAll.
SR-D95367 · Issue 560739
Expanded debug logging for exception blocks
Resolved in Pega Version 8.2.7
In order to enhance debugging, logging has been expanded to capture more detail on exception blocks.
SR-D95410 · Issue 556323
CSS added for currency display place holder when empty
Resolved in Pega Version 8.2.7
After update, currency cell properties displayed a blank space instead of the previous "--" if the value was empty. This was traced to templating and markup changes that resulted in styles related to adding hyphens not getting applied to the inner span, and has been resolved by adding the necessary CSS.
SR-D96224 · Issue 556780
Validation error messages correctly cleared
Resolved in Pega Version 8.2.7
The error message on a checkbox field, radio button, or text area with a on-change post value was persisting even after the correct input was provided. This occurred when the area had a caption, and was due to an additional wrapper span that caused the error div to be the span's sibling instead of the span itself. In the post value success, the system checked whether the error div was present in the area's parent, i.e. span, and when no div was returned the error msg was not removed. It was possible to add an action 'Refresh this section' on change as a workaround, but this has been corrected by updating the system so that Instead of checking the error div in src.parentNode, it will access the correct parentNode using 'closest' and check for the error div.
INC-167606 · Issue 665868
Updated ConfirmHarness handling for case type creation
Resolved in Pega Version 8.5.5
If a new case type was created with the initialization stage and there were no assignments in the case type, the /cases API did not return a NextPageID in response. This has been resolved by setting the pyConfirmHarness parameter before calling addworkobject.
INC-168368 · Issue 651080
Correct flow actions loaded in multi-thread portal refresh
Resolved in Pega Version 8.5.5
The member authentication screen was displaying an incorrect flow action on doing browser refresh after creating a new interaction. Refresh is a special case where the parameter retention is different across single-threaded & multi-threaded portals alongside the execution order of activities. In this case, this inconsistency occurred in a multi-threaded portal when newAssignPage had the information to load the proper assignment but the parameter indicated an old index. This has been resolved by adding 'when' conditions to to populate and pass the correct references and labels and to honor the Param.TaskIndex set and sent by UI activities so it's retained in case of multi-thread portals.
INC-169636 · Issue 649730
WorkObjects security update
Resolved in Pega Version 8.5.5
Cross-site scripting protections have been updated for WorkObjects.
INC-170514 · Issue 653761
Lock conflict resolved for AssignmentCheck
Resolved in Pega Version 8.5.5
The error "Unable to unlock this work object" sporadically appeared in both the runtime log and Pega RULES log when the robot was trying to create a case in Pega using an API call. Investigation showed that as the case was created, it was pulled by another robot (another requestor) which was using the GetAssignments API. This caused the perform assignment check to fail. To resolve this, a 'when' rule has been added to the performAssignmentCheck Activity.