SR-C96786 · Issue 445619
Controls updated to handle hidden values in finishassignment submission
Resolved in Pega Version 8.3
A SECU0001 alert was thrown from the out-of-the-box function finishassignment upon the submit of assignments. This was traced to an alert generated while attempting to post the feed even though there was no Pulse gadget used in the work object, and was due to the handling of hidden fields as read-only. Since the read-only values were not editable, they should not be submitted with the request body; this has been corrected by modifying the hidden control entry handle such that hidden property is considered as editable-filled. Controls have also been added to pxHidden to prevent potential misuse.
SR-C90853 · Issue 488536
Memory leak repaired
Resolved in Pega Version 8.3
A server side memory leak was traced to heap utilization increasing due to a Stream control assembly problem where the CleanForReuse() function was not cleaning up pzAuto. The cleanForReuse method in generated HTML properties is used to either initialize local fields, in which case aContext will be non-null, or to clear the object for pooling, in which case aContext will be null. Because the pzAuto variable was not being properly nullified, pooled controls were retaining stale references to StreamTools, LayoutRuntime, PRThread, and others. This has been resolved by adding code to ensure the pzAuto variable is correctly nullified.
SR-D16884 · Issue 489355
Added handling for cases where Microsoft Internet Explorer causes a SAXParseException
Resolved in Pega Version 8.3
Numerous SAXParseException messages were seen in the log file, and the queryString showed the pyDeleteDocumentPg being referenced. This was traced to the method used by Internet Explorer to construct an HTTP request: Microsoft Internet Explorer sends the header and body of the request in separate TCP packets, but for an unknown reason in this case the body packet goes missing. To resolve this, a toggle has been introduced which will send the pyDeleteDocumentPg request as GET if pega.u.d.GET_REQUEST_DELETEDOCUMENT is set to true in userworkform. In a normal flow without this variable, the request will pass through the normal flow.
SR-D19281 · Issue 490124
Added handling for cases where Microsoft Internet Explorer causes a SAXParseException
Resolved in Pega Version 8.3
Numerous SAXParseException messages were seen in the log file, and the queryString showed the pyDeleteDocumentPg being referenced. This was traced to the method used by Internet Explorer to construct an HTTP request: Microsoft Internet Explorer sends the header and body of the request in separate TCP packets, but for an unknown reason in this case the body packet goes missing. To resolve this, a toggle has been introduced which will send the pyDeleteDocumentPg request as GET if pega.u.d.GET_REQUEST_DELETEDOCUMENT is set to true in userworkform. In a normal flow without this variable, the request will pass through the normal flow.
SR-D38415 · Issue 507995
Resolved Transfer to Queue duplicate assignments
Resolved in Pega Version 8.2.4
The Transfer to a Queue option was creating duplicate assignments after accepting the Chat. Once the chat was accepted, an instance was created\maintained in both Assign-Workbasket and Assign-Worklist tables. This happened after adding the "Transfers" queue to an Agent; if that queue was not added, the transfer to a queue option gave an error to the Agent receiving\accepting the chat. The Work-.ReassignDefaults activity is an extension that was customized in the Pega-DecisionManager ruleset for a certain use case in revision management. The customization is no longer required and has become redundant and has therefore been removed to resolve this issue.
SR-B36632 · Issue 292416
Improved logic for cloned operators and workpools
Resolved in Pega Version 7.3
The workpools available in a new application were not updating correctly due to a missed use case related to multiple cloned operators and the respective multiple cloned workpools being added to the built-on operator. To better handle this scenario, the following changes have been implemented: 1) If the workpool originally listed on the access group to be cloned derives from a class in the list of classes to be created, then the entry will be updated with the new work pool name. 2) If the workpool originally listed on the access group to be cloned does NOT derive from a class in the list of classes to be created, then the entry will be removed from the new access group. (for example, if the user selected no case types and the old access group had multiple work pools listed, then none of those workpools will be present on the new access group since those work pools were not cloned). 3) If an entry was previously marked as the default work pool, the newly cloned workpool will be marked as the default workpool. (This is a change in logic, as previously the access group always used the default work pool [Org-App-Work]). 4) If the previous default work pool was not cloned to the new application (based on case type selection), then the access group's default workpool will be the first in the list. 5) If there were no work pools present in the list, then the standard Org-App-Work classgroup that is always created as part of the new application process will be added and made the default.
SR-B36632 · Issue 294145
Improved logic for cloned operators and workpools
Resolved in Pega Version 7.3
The workpools available in a new application were not updating correctly due to a missed use case related to multiple cloned operators and the respective multiple cloned workpools being added to the built-on operator. To better handle this scenario, the following changes have been implemented: 1) If the workpool originally listed on the access group to be cloned derives from a class in the list of classes to be created, then the entry will be updated with the new work pool name. 2) If the workpool originally listed on the access group to be cloned does NOT derive from a class in the list of classes to be created, then the entry will be removed from the new access group. (for example, if the user selected no case types and the old access group had multiple work pools listed, then none of those workpools will be present on the new access group since those work pools were not cloned). 3) If an entry was previously marked as the default work pool, the newly cloned workpool will be marked as the default workpool. (This is a change in logic, as previously the access group always used the default work pool [Org-App-Work]). 4) If the previous default work pool was not cloned to the new application (based on case type selection), then the access group's default workpool will be the first in the list. 5) If there were no work pools present in the list, then the standard Org-App-Work classgroup that is always created as part of the new application process will be added and made the default.
SR-B12993 · Issue 285730
Property change tracking updates for source shapes and ClipboardPageAdapter
Resolved in Pega Version 7.3
OnChange and Declare Expression rules were unexpectedly triggered during data flow executions that converted clipboard pages from DSM to regular implementation. The triggering also intermittently occurred when loading data from different dataset types while populating the page. This was traced to the handling of property change tracking, and the system has been updated so that source shapes and ClipboardPageAdapter will not track property changes.
SR-C75566 · Issue 420775
Added null check to avoid DisplayCardAccountHeader rendering issue
Resolved in Pega Version 8.3
When the out of the box section DisplayCardAccountHeader was created by View editor and then converted to full section editor, the embedded sections were empty or not seen. This was traced to the design view javascript hitting an error which caused the design view rendering to fail. To correct this, pzpega_ud_gridlayout_model has been updated to wrap the line in question with a null check and set the value to empty string if it doesn't already exist in the model.
SR-C84116 · Issue 423755
Added container handling to make optimized grid table visible in action top
Resolved in Pega Version 8.3
After upgrade, if the Optimize code checkbox was checked on a table and visibility was applied over grid header, the table was not visible in the UI. This scenario only happened when a grid was upgraded from non-optimized to optimized with some visibility condition added, and was caused by the system not yet supporting the visibility features in action top for an optimized grid. To resolve this at this time, the system has been updated to not honor the visibility at container for an optimized grid so the table will be visible.