SR-C8702 · Issue 349662
Fixed cataloging for framework hotfixes with non-java code
Resolved in Pega Version 7.4
The system was unable to catalog Strategic Application hotfixes that included non-java code instances (e.g. .xml or .properties files) due to Framework hotfixes using a different version format that caused validation failure. To correct this, the system will bypass redundant release version validation for Strategic Application hotfixes so that it can catalog non-java code instances.
SR-C8702 · Issue 344809
Fixed cataloging for framework hotfixes with non-java code
Resolved in Pega Version 7.4
The system was unable to catalog Strategic Application hotfixes that included non-java code instances (e.g. .xml or .properties files) due to Framework hotfixes using a different version format that caused validation failure. To correct this, the system will bypass redundant release version validation for Strategic Application hotfixes so that it can catalog non-java code instances.
SR-B47858 · Issue 304348
Access Group Guardrail warning removed from password change
Resolved in Pega Version 7.4
Changing the password for the '[email protected]' operator generated the warning: 'The same Access Group should not be shared by Operators and Requestor Types. Access group PRPC:Agents was also referenced by Requestor Type DATA-ADMIN-REQUESTOR PRPC!BATCH'. The password change did take effect as expected. This guardrail warning was shown if the Access group used by the [email protected] operator, i.e. PRPC:Agents, was specified in any of Data-Admin-Requestor instance, and has been resolved by removing the unnecessary check.
SR-B96972 · Issue 343423
Specification rule save-as loads requirements
Resolved in Pega Version 7.4
While doing 'Save As' of a Specification rule from a locked ruleset version to a higher unlocked version of the ruleset, the linked Requirements were not shown in the Requirements section under the Details tab. Sometimes a refresh would show the requirements, but intermittently an exception would be generated. This was traced to the system not auto-populating the requirements list on 'save as' of the specification, and code has been added to PostActionSaveAs of the 'Rule-Application-UseCase' class to populate the Requirements link on 'save as' of this rule.
SR-C98068 · Issue 483991
Installer files updated with class loader conflict resolution assistance
Resolved in Pega Version 8.2.4
When sending emails with attachments, errors were observed relating to a loader constraint violation indicating that when resolving interface method, the class loader of the current class and the class loader for the method's defining class had different Class objects for the type used in the signature. The resolution for this requires user configuration of the app server, and the following files for the install guide have been updated with the appropriate information:Deployment-guides-dita/install.ditamap Deployment-guides-dita/Content/Topics/app-server-config/creating-jdbc-driver-module-jboss-tsk.dita Deployment-guides-dita/Content/Topics/app-server-config/delegating-javax-activation-to-JRE-loader-tsk.dita
SR-D28460 · Issue 509365
Added timeout handling for non-PRAuth servlets
Resolved in Pega Version 8.2.4
After logging in via external authentication service (SAML Single Sign On) and setting up a timeout in the access group RuleForm, when the user performed any action and the server identified the request to be timed-out, it was expected that a SAML request would be sent from the browser to the external Authentication Server (referred as IDP) and the flow would proceed from there. This worked as expected for a non-AJAX request. To resolve this, handling has been added for timeout when using non-PRAuth authentication services.
SR-D29127 · Issue 506863
SAML data pages restored after passivation
Resolved in Pega Version 8.2.4
If login used SAML SSO, resuming the session after passivation resulted in missing or empty data pages when using an SAP integration with Pega Cloud. This was traced to a security change that modified the D_SAMLAssertionDataPage and D_SamlSsoLoginInfo data pages as readonly, causing them to not be passivated under these conditions. To resolve this, the data pages have been made editable so they will be restored as expected. This change also resolves any difficulty with SAML logoff activities in conjunction with SAP and Pega Cloud.
SR-D37872 · Issue 507341
prproductmigration build.gradle updated for new mime4j asset name
Resolved in Pega Version 8.2.4
While running the getMigrationLog for ProductMigration script provided in the Pega 8.2.2 media files, errors appeared referencing "NoClassDefFoundErrors when running getLogs". This was caused by the referenced class not being found on the classpath: the version of the included jar did not include the class needed due to Praxiom's default version being updated to use a new version of mime4j that required an asset name change. To resolve this, the mime4j asset name in prproductmigration build.gradle has been updated to pick up the correct version of the dependency for Praxiom.
SR-D32972 · Issue 513488
HTML entity handling added to URLObfuscation
Resolved in Pega Version 8.2.5
When URLObfuscation was enabled through the configuration settings, clicking on Operator -> Profile page generated an ArrayIndexOutOfBoundException. When obfuscation is used the decrypted string is parsed and the request map is populated, but HTML entities were not considered during this process. To resolve this, handling has been added for HTML entities and characters during obfuscation. Please note: URL Obfuscation is a legacy feature with many known limitations and it is no longer recommended that these settings be used.
SR-D37894 · Issue 505975
Query parameters will be cleared after redirection from authentication
Resolved in Pega Version 8.2.5
When using the /PRAuth Servlet, running a snapstart URL generated from a secondary application correctly executed SAML Authentication and Pega processing, but a second URL generated with different parameters ran with the parameters from the first request. The third and subsequent requests processed as expected with the parameters sent in with the request. Investigation showed that the previous parameters were picked due to the query string parameters not being cleared after redirection, and this issue has been resolved by updating the system so it will clear the parameters after issuing a redirect from the authentication policy engine.