SR-C80129 · Issue 425385
Enhancement added to hide class join warning from end user
Resolved in Pega Version 8.1.4
An enhancement has been added to hide the joined class warning message at the end user portal if the section pzManageRecords is delegated to the user. This is done by by checking pxLimitedAccess on the pxThread clipboard page.
SR-C78006 · Issue 425510
Wait corrected for sub case after reopening
Resolved in Pega Version 8.3
A re-opened parent case was not waiting for the sub case when a sub case was reopened, but it did wait if there was no sub case on the reopened parent case. This has been resolved by enhancing the system to better handle the reopen of activator and dependent work objects by checking the reopen time: - pzGetAllStatusforDepClass activity: added step 2 to consider activator reopen time - pzGetMessageKeysForFlowDependencies list view: added criteria to filter on reopen time
SR-C81829 · Issue 425617
pxCoveredCountOpen value decrease corrected
Resolved in Pega Version 8.3
When a flow reached the resolved stage (Resolved-Withdrawn), pxCoveredCountOpen was reducing the count by 2 instead of 1, eventually causing the value to go negative and prevent any further work objects from being marked as Withdrawn. Investigation showed the "Update status" activity was being called twice due to the Temporary WorkPage used to delete assignments persisting and appearing as a duplicate pyWorkPage. This caused an issue when using findPage by pzInsKey. To correct this, the "pxDeleteAssignmentsForWork" activity for Step-15 has been modified to explicitly remove the temporary WorkPage after the assignment is deleted.
SR-C65841 · Issue 425805
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-C86770 · Issue 426050
Case urgency value will not be reset when processing wait shapes
Resolved in Pega Version 8.3
When a Wait shape was configured with the ‘Users can choose to continue process’ option unchecked, the overall work object SLA urgency was overwritten to 0 when the SLA processed the Wait shape. This was due to the Wait shape using pzWaitTImer, which has all urgency values as 0. The SLA being set to 0 did not occur if ‘Users can choose to continue process’ was checked on the Wait shape because pxSystemFlow was not set to true in that case. To prevent the SLA override, a check has been added that will skip setting the urgency setting if there is a wait shape.
SR-C82453 · Issue 426075
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-C89316 · Issue 426076
Lower major ruleset versions will not be considered during design time validation
Resolved in Pega Version 8.3
After circumstancing a rule by property and withdrawing the rule in higher version, the same rule was circumstanced by template. Later after major skimming, attempting to perform a save-as of the circumstanced template rule resulted in an error stating that the circumstanced property already existed. During design time, the system validated the rule with rules from all other ruleset versions. In this corner case where a property-based circumstanced rule was withdrawn and then skimming was performed, the error occurred because it was being saved in a different major ruleset instead of into the same major ruleset. In order to better handle this condition, the system will not consider rules from lower major versions during design time validation.
SR-C79366 · Issue 426093
Corrected issue with Field Level Auditing re-adding deleted page list items
Resolved in Pega Version 8.3
Pressing a Save button that invoked the pyTrackSecurityChanges data transform caused deleted items to be added back to a page list. This was caused by pyPropertyIndex being set on the removed page in RUF-pzAddHistoryMemosForPageList, and has been corrected by removing that unneeded action.
SR-C87399 · Issue 426184
pzEditSkills activity updated for better skill matching
Resolved in Pega Version 8.3
In the pzEditSkills activity, a select skill is added to the operator. A check is made using a comparison of pyRuleName equal to pySkillLabel to see whether this skill exists in the system; if it exists it is directly added to the operator profile, and if it does not it is created and added to the operator profile. However, pyRuleName uses a short skill identifier string, for example ‘XML’ whereas pySkillLabel is the longer human readable string, for example ‘XML programming skill’. Therefore, it was possible for Pega to determine the skill did not exist and proceed to creating a new skill with pyRuleName equal to the pySkillLabel of the existing skill in the first available unlocked ruleset. In order to ensure the proper matches are made, the pzEditSkills activity step 4.1 has been modified to get the rule name instead of skill name.
SR-C88948 · Issue 426226
Command-line BIX extract properly exits with failure status if the rule is not found
Resolved in Pega Version 8.3
Running a BIX extract from the command line was returning 0 for both success and failure. This was caused by the error message in this scenario not properly setting the flag if an extract rule did not exist, and has been corrected to ensure the command exits with status code 1 if it is not able to get the list of extract rules.