SR-A94083 · Issue 266677
SaveCovered checks for stale Cover
Resolved in Pega Version 7.2.2
When resolving a Covered work object, a stale copy of the Cover was being saved which resulted in the opened Cover assignment becoming invalid. This was caused by the SaveCovered function not checking to see if pyWorkCover was stale or not before calling RecalculateAndSave. This has been resolved by adding steps in SaveCovered to check if pyWorkCover is stale and to open pyWorkCover if it is stale using Obj-Open-By-Handle.
SR-A97281 · Issue 263948
SaveCovered checks for stale Cover
Resolved in Pega Version 7.2.2
When resolving a Covered work object, a stale copy of the Cover was being saved which resulted in the opened Cover assignment becoming invalid. This was caused by the SaveCovered function not checking to see if pyWorkCover was stale or not before calling RecalculateAndSave. This has been resolved by adding steps in SaveCovered to check if pyWorkCover is stale and to open pyWorkCover if it is stale using Obj-Open-By-Handle.
SR-A99477 · Issue 266058
SaveCovered checks for stale Cover
Resolved in Pega Version 7.2.2
When resolving a Covered work object, a stale copy of the Cover was being saved which resulted in the opened Cover assignment becoming invalid. This was caused by the SaveCovered function not checking to see if pyWorkCover was stale or not before calling RecalculateAndSave. This has been resolved by adding steps in SaveCovered to check if pyWorkCover is stale and to open pyWorkCover if it is stale using Obj-Open-By-Handle.
SR-A96203 · Issue 270094
CreateCase rollback corrected
Resolved in Pega Version 7.2.2
While creating a sub-case and getting an error on any end-step of flow, Pega starts the rollback of the process, but was saving pxCoveredInsKeys in the Clipboard page of Case. This was a missing use case in AddCoveredWork to call RemoveFromCover if an error was thrown while creating a child case along with copying page pages from cover to primary, and has been corrected.
SR-A96203 · Issue 266909
CreateCase rollback corrected
Resolved in Pega Version 7.2.2
While creating a sub-case and getting an error on any end-step of flow, Pega starts the rollback of the process, but was saving pxCoveredInsKeys in the Clipboard page of Case. This was a missing use case in AddCoveredWork to call RemoveFromCover if an error was thrown while creating a child case along with copying page pages from cover to primary, and has been corrected.
SR-A91680 · Issue 259008
Resolved Null Pointer Error for resubmit of a corrected case with optimistic locking
Resolved in Pega Version 7.2.2
Work order case creation was throwing a null pointer exception in logs if optimistic locking was enabled on the case type and the case was resubmitted after correcting a validation error. This has been fixed with the addition of a null check for a clipboard page in use.
SR-A99040 · Issue 268520
Cleared email field in FieldMarketer campaign remains blank
Resolved in Pega Version 7.2.2
If the Email field of a FieldMarketer campaign was cleared and saved, closing and then reopening the session filled the email field with the Operator ID, which is not a valid email address. This was traced to Operator Email always defaulting to OperatorID if empty, and the activity has now been modified to not set the email field if empty.
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.