SR-D13 · Issue 434981
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-D2530 · Issue 445609
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-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-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.
INC-179622 · Issue 659155
Flow action list available in navigation menu
Resolved in Pega Version 8.6.1
After update, only one flow action which had highest likelihood was visible when an assignment in a flow had multiple flow actions. Alternatives were not visible in the Action menu. This was an unintended side effect of work done to simplify the Actions menu which did not consider the usecase of an alternate flow action being configured, and has been resolved by restoring the flow action list to the navigation menu in pyWorkCommonActions.