SR-B31665 · Issue 291063
TaskMethodHeader RUF updated to pass the param page
Resolved in Pega Version 7.3
The activity method History-Add was not adding pyTaskName in Flow FUA. This was caused by a difference in handling: Status Update via an Assignment uses the UpdateStatus activity by passing a new parameter page with only the target status value to be updated. Status Update via a Utility uses the same UpdateStatus activity by passing a parameter page created using the "CreateNewParamsPage" private method with all the required information. In order to ensure all of the needed information is available, the TaskMethodHeader RUF has now been updated to pass the param page by calling the "CreateNewParamsPage" private method.
SR-B31667 · Issue 291704
Consistent Work IDs between case types created in different implementations
Resolved in Pega Version 7.3
Creating an Implementation layer on the Warranty application using the New Application wizard of Pega 7.22 GA was resulting in a different Work ID prefix of some case types like Claim Unit or Appeal than when the same case types were created in the built on application. This was traced to different activities being used to populate the data page, and has been updated to ensure uniform work ID generation.
SR-B31748 · Issue 291859
Stage SLA urgency correctly updates
Resolved in Pega Version 7.3
Stage SLA was updating the wrong urgency property due to the urgency value being added twice. The ExecuteSLA activity has been modified to make sure that urgency value for stage and step are updated correctly.
SR-B31818 · Issue 292373
Security update for URL string queries
Resolved in Pega Version 7.3
To ensure sensitive information is not exposed in transit between the client and server via URL query string parameters, pyCaseManager Menu and pzGetUserProfile activity have been updated to avoid passing the user ID as a parameter.
SR-B31818 · Issue 292752
Security update for URL string queries
Resolved in Pega Version 7.3
To ensure sensitive information is not exposed in transit between the client and server via URL query string parameters, pyCaseManager Menu and pzGetUserProfile activity have been updated to avoid passing the user ID as a parameter.
SR-B31876 · Issue 290136
Correspondence logic corrected for party ID
Resolved in Pega Version 7.3
When using the Send Email smart shape to send correspondence to work party, party Roles containing the string "Owner" (such as "AAOwner") caused the correspondence to be sent to the email address of the "Owner" party instead of the "AAOwner" party. This was caused by a logic error in the party list iteration that used 'contains' instead of 'equals', and has been fixed.
SR-B33088 · Issue 293375
pyGetAttachmentContent modified to access class for new properties
Resolved in Pega Version 7.3
The out-of-the-box properties IsDataPageRefreshed and PxAttachName were generating errors indicating the page contains undefined properties. The issue was with the activity pyGetAttachmentContent. As the properties pxAttachName and pyURL etc. are present in their respective classes and the data page class is Data- the errors were not visible. To correct this, pyGetAttachmentContent has been modified to use Page-Change-Class in the activity to change to the correct class so that properties can be accessed. pzRemoveAttachments and pzRefreshAttachmentList have also been updated to use pyIsDataPageRefreshed (new property created).
SR-B33387 · Issue 298483
Incorporated synchronized timestamp function for addWarning
Resolved in Pega Version 7.3
When the pxWarningCreatedDateTime was the same for two warnings with the same pxWarningName, one of the warnings was not getting justified. To fix this, the addWarning function will use the synchronized timestamp function getCurrentDateTimeUnique() to generate the created time.
SR-B33678 · Issue 292086
Bulk process with only 'case type any' properly assigns all processes
Resolved in Pega Version 7.3
When using Bulk Process with "Bulk Process in Background" checked and only the filter 'Case type is any', only the first process was getting assigned to the operator. This was due to the agent name not being properly set while populating the queue with this filter, and has been corrected.
SR-B33678 · Issue 292524
Bulk process with only 'case type any' properly assigns all processes
Resolved in Pega Version 7.3
When using Bulk Process with "Bulk Process in Background" checked and only the filter 'Case type is any', only the first process was getting assigned to the operator. This was due to the agent name not being properly set while populating the queue with this filter, and has been corrected.