SR-D77658 · Issue 542844
Updated backwards compatibility for custom date/time with extra text
Resolved in Pega Version 8.3.2
After upgrade, migrated extra text in the custom date format was causing confusion. The previous support of additional text on earlier versions was not intentional, but was allowed by the previous default of non-template mode. In template mode, when custom datetime format includes plain text in single quotes, pega.ui.Formatter.formatDateTime processes the entire format string instead of only the datetime formats. To avoid confusion, updates have been made so if a custom format has plain text in quotes, the system will separate the formats and resolve them.
SR-D78019 · Issue 541192
Thread Cleanup error resolved
Resolved in Pega Version 8.3.2
After upgrade, intermittent exception errors were being generated by the FreeClipboard activity when switching between applications. This was traced to specific use-case issues with Thread Cleanup, and has been resolved.
SR-D78562 · Issue 543529
Calendar Mode accessibility enhanced
Resolved in Pega Version 8.3.2
Accessibility has been added for datetime control's calendar mode by adding alternative text and an aria-label for the image icon with a value from fieldvalue "Choose from calendar".
SR-D79103 · Issue 543136
Corrected Finish Assignment error
Resolved in Pega Version 8.3.2
When trying to open a resolved case using the "open assignment" action in a button by passing an assignment key, finish assignment was not working. This was traced to context not being correctly set before querying for the errorDiv for removal, and has been resolved by explicitly setting the current context before removing the errordiv.
SR-D79777 · Issue 542046
Corrected top navigation rendering for Robot Manager harness with parameters
Resolved in Pega Version 8.3.2
When using "Robot Manager", a Single Doc, top navigation enabled portal, with pre DTs or Activities provided to launch a new harness on click of links from multiple places, an invalid data error appeared when a new Harness was rendered as part of some button or link click. If the the tab was closed and the Robot Manager portal was initiated from Dev studio, invalid data was loaded. This was traced to a missing use case for loading the portal center-panel harness when it was configured with preactivity and preDT with parameters. To resolve this, the showdesktop activity has been updated to handle preDT and preactivity parameters of the launch harness action.
SR-D80223 · Issue 542921
Cross-site scripting filtering for ActionStringID
Resolved in Pega Version 8.3.2
Cross-site scripting filter logic has been added to the ActionStringID function.
SR-D81779 · Issue 543855
Logic added to prevent refresh on enter when no action is configured
Resolved in Pega Version 8.3.2
After configuring a text input followed by an icon with display SmartInfo for click action, switching focus to the text input again after displaying the SmartInfo and hitting enter invoked the refresh harness even though no action was configured for the text input. This has been resolved by updating 'pzpega_ui_events.js' -> keyDownHandler() with logic to call preventDefault() based on certain conditions.
SR-D81900 · Issue 544327
Thread Cleanup error resolved
Resolved in Pega Version 8.3.2
After upgrade, intermittent exception errors were being generated by the FreeClipboard activity when switching between applications. This was traced to specific use-case issues with Thread Cleanup, and has been resolved.
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.