INC-159334 · Issue 626764
Handling added for custom attachment method
Resolved in Pega Version 8.5.3
When sending a correspondence using the standard SendSimpleEmail activity, choosing only one attachment from the multiple attachments in the work object by passing the pxLinkedRefTo property from the clipboard page to the AttachmentKeysToSend parameter instead of passing the value to the AttachmentCategoriesToSend parameter successfully sent the message and attached it to the work object. However, opening the correspondence attached to the work object showed the attached file as blank even though the attachment was present in the receiver�s email. Research showed that during the comparison of keys in place of pxLinkedRefTo, pzinskey was used. This caused the comparison to not register as true and the attachments display was skipped. This has been resolved by updating the Data-Corr-Email.Show Html rule to use the pxLinkedRefTo field to find the right attachment. The URL encryption was also updated to ensure the links are functional and attachments can be downloaded.
INC-160078 · Issue 628840
Work object status correctly set to Resolved after refresh
Resolved in Pega Version 8.5.3
When using the Refresh option from the Other Actions menu before submitting the flow action, the work object status was not updating to Resolved-Completed. Investigation showed that when performing the Refresh action, the RefreshOnConflicts activity created a Clipboard page named LatestWorkPage with a copy of the work object. This page was not removed after use, causing the Resolved-Completed status to be set on LatestWorkPage instead of pyWorkPage. To resolve this, a step has been added to RefreshOnConflicts to remove LatestWorkPage.
INC-160115 · Issue 627651
Editing Approval flowshape retains decision tree
Resolved in Pega Version 8.5.3
Editing the Approval flowshape caused the decision tree to become blank when selecting 'Use Business logic' in the dropdown for "Route to dropdown". This was traced to a missed use case for earlier work done on enhancements for email approver shapes regarding retaining previous values while switching back to using the business logic option, and has been resolved.
INC-160420 · Issue 627961
RefreshFor correctly returns validation messages
Resolved in Pega Version 8.5.3
After upgrade, the PUT method on /api/v1/assignments/{ID}/actions/{actionID}/refresh?refreshFor was not returning validation messages on the child level. This was an unintended consequence of refactoring work done on pzApiCreateJsonForField around the default value calculation, and has been resolved.
INC-161463 · Issue 638003
Case Dependency corrected for different access groups
Resolved in Pega Version 8.7
Creating a queue item as part of the case dependency was not working as expected when the access groups of the dependent cases were different. Investigation showed that in this scenario, the logic was looping differently and the DependencyList page in pxCheckFlowDependencies was getting removed. To resolve this, the DependencyList page has been moved so it is processed inside the DependencyList.pxResults loop.
INC-161948 · Issue 638963
Locking settings enabled for circumstanced case types
Resolved in Pega Version 8.7
Optimistic locking options were not present for a circumstanced case type, and the option to select the "Lock parent case when an action is performed on this case" check box was not available. However, when the parent case type was enabled with optimistic locking, a circumstanced child case could inherit a lock from its parent. Because "Lock parent case when an action is performed on this case" was not enabled on the circumstanced child case type, trying to update the parent case from the child case and save the parent case resulted in a "Lock not held on parent" error. This was a missed use case, and has been resolved by enabling locking settings in Case Designer for circumstanced case types.
INC-162168 · Issue 644731
Refresh works for nested lists
Resolved in Pega Version 8.7
After creating Pagelist A with another Pagelist within (B), a section was created with a repeating dynamic layout to display Pagelist A and a button was added with action set to refresh this section. In the embedded section of the repeating dynamic layout, a nested repeating dynamic layout was created for Pagelist B and a button was set to refresh this section. When using this configuration, the refresh was returning the actionID for Pagelist A regardless of which button was used. To resolve this, an update has been made which will iterate over the stack and append the individual indexes to the encoded value in the pzAPICreateJsonForField function.
INC-162763 · Issue 646109
Case creation and Save As performance improvements
Resolved in Pega Version 8.7
Performance improvements have been made to the getApplicationRuleSetList() function to avoid unnecessary and repetitive database calls.
INC-163154 · Issue 638100
Code updated for bulk actions buttons
Resolved in Pega Version 8.7
After upgrade, hovering over the "Filter case" button in pzBullkUpdate and the "Create" and "Clear" buttons in pzBulkAddActions caused them to disappear. The warning "This button generates markup that was used to support the older browsers. It is recommended that you update it to the newer markup" was shown, and an update code button appeared. Some custom rules exhibited the same behavior initially, but worked as expected after updating the code and saving them. This has been resolved by updating the buttons in pzBulkUpdate and pzAddBulkActions with the latest UI technologies used for button control codes.
INC-168368 · Issue 651081
Correct flow actions loaded in multi-thread portal refresh
Resolved in Pega Version 8.7
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.