SR-B71077 · Issue 326659
IDP Encrypted connections working on SAML
Resolved in Pega Version 7.3.1
IDP initiated SAML 2.0 was not working, and generated the error "Unable to process the SAML WebSSO request : Missing Relaystate information in IDP Response". Authentication worked fine with unencrypted SAML token. This schema validation failure happened because encrypted attributes were previously being ignored by Pega due to an issue in the underlying openSAML library. To resolve this, a custom PegaSAMLValidator has been inserted to validate the assertion and honor encrypted attributes.
SR-B65744 · Issue 315671
Repaired use of custom case ID search
Resolved in Pega Version 7.3.1
After upgrade, custom search criteria for case IDs generated an error when pulling data from the database. This was traced to a change that removed CommonTLP as a fallback, and that default has been restored.
SR-B55660 · Issue 316375
Removed "SHA1" hard coding from SAMLRedirectBindingHandler
Resolved in Pega Version 7.3.1
SAML logout failure was seen after using SHA256 signature encoding on an IDP that does not support SOAP. Previously,"SHA1" was hard coded to be used for verification of certificate during logout in the case of HTTP-Redirect Binding; this hard coding has now been removed from SAMLRedirectBindingHandler.verify() .
SR-B45960 · Issue 303751
Request & Response logs include POST method submits
Resolved in Pega Version 7.3.1
When using the POST method to send a request, request & response data was not showing up the in DEBUG logs of the Connect-REST execution. This has been corrected, and request & response data is now being added to DEBUG logs in Connect-REST execution.
SR-B49398 · Issue 306482
Request & Response logs include POST method submits
Resolved in Pega Version 7.3.1
When using the POST method to send a request, request & response data was not showing up the in DEBUG logs of the Connect-REST execution. This has been corrected, and request & response data is now being added to DEBUG logs in Connect-REST execution.
SR-B69082 · Issue 317647
Support added to data import wizard for Enhanced Work ID prefix/suffix
Resolved in Pega Version 7.3.1
While creating work objects using the data import wizard, the pyID did not include a suffix that had been added to the work object ID. This was due to custom logic for generating workId being called in DataImportUtilsImpl rather than reusing the existing activity GenerateID in Work- class. In the custom logic, suffixId is not used and therefore was not passed. To improve flexibility, changes have been made in the import code to call the activity GenerateID for generating the WorkID using both the prefix and the suffix ID.
SR-B50950 · Issue 308958
Connect-SOAP passivation tuned
Resolved in Pega Version 7.3.1
Connect-SOAP implementation uses requestor instance to cache STSConfigContext and Axis2 ServiceClient objects; these are not serialize-able and were leading to requestor passivation failure. As part of the fix, these objects will be de-referenced from the requestor page and instead the system will use a requestor scoped data page to cache STSConfigContext and Axis2 ServiceClient objects.
SR-B66457 · Issue 315578
Date time values corrected for data loader uploads
Resolved in Pega Version 7.3.1
Using data loaders to upload a work object which contained date fields was resulting the the fields taking the wrong dates. To correct this, from the second record onwards the system will use the parseDateTimeWithISO method in order to consider both basic date time and XSD date time instead of only XSD date time
SR-B66457 · Issue 315580
Date time values corrected for data loader uploads
Resolved in Pega Version 7.3.1
Using data loaders to upload a work object which contained date fields was resulting the the fields taking the wrong dates. To correct this, from the second record onwards the system will use the parseDateTimeWithISO method in order to consider both basic date time and XSD date time instead of only XSD date time
SR-B72326 · Issue 325267
EmailListener handling updated for addressee errors
Resolved in Pega Version 7.3.1
When messages are handled by the EmailListener with more than one recipient (more than one TO: header and even sometimes more than one CC: header), the EmailListener activity will create a (sub-)case for each of these recipients, based on their email addresses from the TO: or CC: list. If an error was generated by one of the recipient email addresses in one of the groups (TO: or CC:) being invalid, only the invalid address was returned to the EmailListener for further processing. This meant the other addresses in the same group were ignored and no (sub-)case created for them. To address this issue, the handling has been changed: If an exception occurs while processing a recipient's name, the system will iterate through the Message to get recipients one by one. If the Address is valid it will be added to the list, and if it's invalid then extractEmailAddress API will be used to attempt to extract a valid email address and add it. If the extraction did not obtain a valid email address it will be logged and ignored. Please note that all this processing will be done if FailOnAddressException DSS is set to false (the existing behavior).