SR-D86978 · Issue 549173
Export to Excel cell style control added
Resolved in Pega Version 8.4.1
If a column was formatted with an auto generated numeric control, a new cell style was generated for every row during the export to Excel process. Since there is a limit on the amount of cell styles, once the number of rows in the file was greater than 64000 an error was generated. To resolve this, the system will disable the creation of a new cell style for every instance when an auto-generated numeric control is used.
SR-D68235 · Issue 534783
Stale WorkSearchPreference data cleared when switching apps
Resolved in Pega Version 8.4.1
The D_pyWorkSearchPreferences data page data was not refreshing while switching between apps, causing stale data to be populated under the case search dropdown for all the applications after switching the application from one to another. This has been resolved by removing the D_pyWorkSearchPreferences data page as part of pzProcessApplicationSwitch.
SR-D73536 · Issue 538403
FetchApplicationLogo modified to Filter by rule resolution
Resolved in Pega Version 8.4.1
It was observed that the Report Definition rule "pzFetchApplicationLogo", referenced by Activity rule "pzLoadApplicationLogo", always returned the older version of the Binary File "webwb • pyapp-logo • svg" because it had been set to retrieve a maximum of one record and in this case the results were sorted in an order where the oldest record was at the top. As the Report Definition did not indicate any sorting, most DBMS were returning the results in no particular or predictable order. To resolve this, "Filter by rule resolution" has now been enabled for RD pzFetchApplicationLogo.
SR-D76291 · Issue 547843
Updated retry logic for S3 AddAttachmentFromEmail
Resolved in Pega Version 8.4.1
When using the AddAttachmentFromEmail activity with S3 repositories, performing an obj-save on the data-workattach-file page executes a deferred save while also saving the file into the repository. if the data was inserted into S3 successfully but encountered an issue when saving the related data-work-attach-file page, the system was trying to call the save operation again. This tried to insert the duplicate attachment again to S3, causing an error on that side of the process. To resolve this, the duplicate Obj-Save functionality in AddAttachmentFromMail Activity has been removed.
SR-D79113 · Issue 543723
Updated DisplayAttachment to handle SIngleClick download from Case Worker portal
Resolved in Pega Version 8.4.1
On using the script "pega.ui.HarnessActions.doAttachmentSingleClick" in the Worker portal to download attachments displayed within a screen flow, the entire application was hanging and no action was invoked even on clicking the Continue or Finish buttons of the screen flow. Whenever an attachment is downloaded using the script function pega.ui.HarnessActions.doAttachmentSingleClick() , an iframe is used and changetracker is called to communicate data between different iframes. However, the case worker portal is a single thread model while the manager and admin portals are multi threaded, which resulted in changetracker freezing on the worker portal. To resolve this, the DisplayAttachment HTML rule has been updated to build the necessary changeTrackerMap for the worker portal.
SR-D84480 · Issue 546189
FilterHistory decision tree used for audit log status
Resolved in Pega Version 8.4.1
Attempting to use the “FilterHistory” decision tree in the work class to return value “false” for “pyCloseOpenAssignmentsOnResolution” to hide the “pyCloseOpenAssignmentsOnResolution” field value (“Unfinished assignments were cleaned up by the system after the completion.. ”) from history was not working as expected, and still returned the audit message. This was due to the system setting this AuditNote parameter within the “pzProcessResolutionStage” activity, where Param.UpdateHistory was set to true always. In order to support more flexibility, the Param.updateHistory paramter in step3 of the pzProcessResolutionStage activity will be set based on the FilterHistory decision tree. When set to false in FilterHistory decision tree, pyCloseOpenAssignmentsOnResolution will be set as false and audit will not be logged.
SR-D84754 · Issue 548165
Resolved erroneous problem assignment error
Resolved in Pega Version 8.4.1
If a user processed a work item while the SLA agent was also attempting to process it, it sometimes resulted in an assignment with the error: "Error: Flow Not At Task." In this scenario, an error message was displayed stating that "Assignment already completed" even though the assignment was not yet finished, causing confusion. Investigation showed that in cases where the success indicator was -28, the assignment was marked as problem assignment even though it was processed. To resolve this, the system has been updated to skip marking the assignment as a problem when the success indicator is -28.
SR-D88141 · Issue 550010
TemplateButton field correctly set read-only
Resolved in Pega Version 8.4.1
When a control was added to a section using the DX API, a pyTemplateButton field was added to the XML definition of the section with read-only set to 'false'. This has been corrected so the pyTemplate Button field does not allow input.
SR-D63307 · Issue 542771
Unneeded class name filter removed from GetRelevantPropertiesForDataType
Resolved in Pega Version 8.4.1
Given one class with a set of properties and another class inherited from the first class containing a relevant records set for class 2, then a new harness did not show the base class fields. Investigation showed that the fields present in the parent class and marked relevant in the case were not being fetched due to pzGetRelevantPropertiesForDataType having a class name filter along with filter by rule resolution. To resolve this, the class name filter has been removed as it is not required due to the report already filtering by rule resolution and relevant class through a join.
SR-D71475 · Issue 538722
Check added to apply values of newAssignPage.pxFormName
Resolved in Pega Version 8.4.1
After upgrade, trying to open existing assignments resulted in a different harness being opened. This was traced to changes in how the property newAssignPage.pxFormName was used, and has been resolved by checking whether the harnesspurpose is dynamic before setting the pxFormName. If formname is already present, the system will proceed with picking the harness from the shape.