SR-127452 · Issue 192406
Case match duplicate check resolved
Resolved in Pega Version 7.1.8
A case match rule to check for duplicates with adding an expression in weighted condition was giving a runtime error due to incorrect page referencing in java step of activity 'RunDuplicateCasesReport' that was attempting to obtain the property from the RD page (which was using a different structure). The page reference has been updated to correct this issue.
SR-130208 · Issue 198155
Handling added for step page call to DeleteAssignment
Resolved in Pega Version 7.1.8
After upgrade, the pxDeleteAssignment with step page Assign-Workbasket was not working as expected. The error was traced to the 'DETERMINELOCKSTRING' activity being available in Work- class while the local customization was passing the Assign- page as the steps page. Handling has been added for cases when the activity gets called on a page other than primary work page.
SR-130526 · Issue 200786
Modified 'save as' to update workgroups across nodes
Resolved in Pega Version 7.1.8
On a multi-node environment, 'Bulk Actions' was not showing all of the workbaskets after a product rule with a workbasket data instance was imported to one node and not others. This was a lookuplist cache issue caused by 'save as' not updating the workgroups, and has been resolved.
SR-130751 · Issue 198798
Clarified handling of unlocked work objects in multinode environments
Resolved in Pega Version 7.1.8
Release lock was not working correctly on a multinode environment. When trying to release the lock from same operator different requestor from different nodes, the error "Unable to unlock this work object" was generated. In a multinode environment, system pulse takes time to update the cache across the nodes, hence the option is not effective immediately. Messaging has been updated to reflect this delay. Once System pulse executes then other requestor will be able to work on this item.
SR-132538 · Issue 201237
Updated RD handling for WorkBasketAssignments
Resolved in Pega Version 7.1.8
After upgrade, if the Assign-WorkBasket pyWorkBasketAssignmentsDefinition report definition included the WHERE criteria .pxSystemFlow== 'FALSE', workbasket assignments for existing cases were not displayed in the harness. This was due to the new PXSYSTEMFLOW column in the pc_assign_workbasket DB table not properly handling this criteria, and a check has been added to resolve this.
SR-129239 · Issue 200337
Added handling for Flow not at Task error
Resolved in Pega Version 7.1.8
Flow not at task and flow removed errors were appearing sporadically. This happened when the trigger fired off the commit inside the post-processing called CorrUpdateNoWO and returned a stale copy of the Workobject, and was complicated by an assumption that was trying to iterate over "pzInternalCaseFlow". This has been addressed in the CORRUPDATENOWO activity.
SR-131217 · Issue 199744
Stopped unexpected trigger caused by attaching note with gadget
Resolved in Pega Version 7.1.8
Declarative rules were being fired every time a note was attached to a work object using the "Notes" gadget (not advanced notes link). To fix this, the pxAttachNote activity has been updated to not trigger the declarative chaining in this scenario.
INC-102005 · Issue 556731
Child case ID prefix preserved
Resolved in Pega Version 8.4.2
When configuring a case as a child case in App Studio, the case ID prefix was cleared out of the field on the Settings tab for the case type. Investigation showed that when the child case was added to the parent case in App studio, pzaddcasetypetoapp was called but the parent activities did not pass the CaseID parameter of the child case type. This caused the CaseID prefix of the child to be null and displayed as blank in the Settings and Application. This has been corrected by ensuring the system will get and set the parameter value.
INC-119754 · Issue 561523
Corrected 'when' rule context for GetCaseDetails
Resolved in Pega Version 8.4.2
The Pega REST API Get Method /cases{CaseID} failed if the Child Case was set with Manual instantiation using a 'when' rule. This was traced to the 'when' rule being resolved using @baseclass instead of the class of the case type, and has been resolved by updating the pzGetCaseDetails activity to evaluate the 'when' rule on the case page.
INC-120608 · Issue 573001
Temporary case creation from Cosmos resolved
Resolved in Pega Version 8.4.2
Creating a temporary case in Cosmos Portal was not working. Investigation showed that the pySkipCreateHarness and pyCreatesTemporaryObject properties were not populating properly on the D_StartingFlows data page, which was traced to the way openSelectedColumns API handles non-exposed columns. To resolve this, the system has been updated to use the openEngine API for opening starting flows if the pySkipNewHarness or pyCreatesTemporaryObject property values are null.