INC-130703 · Issue 597255
Operator provisioning on authentication service corrected
Resolved in Pega Version 8.5.2
When operator provisioning was triggered on user login via authentication service, the error "ModelOperatorName is not valid. Reason: declare page parameters not supported by PropertyReference" was generated. This was traced to optimization work that had been done on the expression evaluation for operator identification, and has been resolved by adding the required GRS Syntax support in the Operator Provisioning section in SAML and OIDC.
INC-177737 · Issue 663141
Authentication requirement updated for CallConnector
Resolved in Pega Version 8.7
After update, invoking a REST API call during SSO login which eventually called pxCallConnector (Final Activity) in @baseclass Pega-RulesEngine failed at the CallConnector step. This was caused by a change in recent Pega versions which enabled authentication for this activity, and has been resolved by marking the activity as internal and disabling the authentication requirement.
SR-D25972 · Issue 501482
Handling added for custom error message in post-authentication activity
Resolved in Pega Version 8.2.4
The error message in post authentication activity was always appearing as 'Login terminated because a post-authentication activity or policy failed' irrespective of the actual message being conditionally set in the activity based on post authentication logic. Investigation showed that the parameter page in the SSO post-authentication activity was not being passed to the 'pzShowAuthPolicyError' activity due to the post-authentication activity executing in authenticated context whereas the HTML fragment executed in the un-authenticated context. In order to support this use, post-authentication activity will set the error message on a predefined property and propagate that to the HTML fragment by appending the error message as a query parameter in the redirect exception URL post-authentication failure.
INC-187553 · Issue 675429
Service Email handling updated for MSGraph "From" address
Resolved in Pega Version 8.7
While creating cases via email listener, the "From" address was not shown when using MSGraph. This was an issue with extracting the display name when MSGraph is used, and has been resolved by adding double quotes to display the name unconditionally.
INC-188080 · Issue 673783
Service Email handling updated for MSGraph "From" address
Resolved in Pega Version 8.7
While creating cases via email listener, the "From" address was not shown when using MSGraph. This was an issue with extracting the display name when MSGraph is used, and has been resolved by adding double quotes to display the name unconditionally.
INC-188143 · Issue 674972
Service Email handling updated for MSGraph "From" address
Resolved in Pega Version 8.7
While creating cases via email listener, the "From" address was not shown when using MSGraph. This was an issue with extracting the display name when MSGraph is used, and has been resolved by adding double quotes to display the name unconditionally.
INC-189477 · Issue 674034
Service Email handling updated for MSGraph "From" address
Resolved in Pega Version 8.7
While creating cases via email listener, the "From" address was not shown when using MSGraph. This was an issue with extracting the display name when MSGraph is used, and has been resolved by adding double quotes to display the name unconditionally.
INC-200029 · Issue 690167
Service Email handling updated for MSGraph "From" address
Resolved in Pega Version 8.7
While creating cases via email listener, the "From" address was not shown when using MSGraph. This was an issue with extracting the display name when MSGraph is used, and has been resolved by adding double quotes to display the name unconditionally.
INC-157448 · Issue 638925
Latitude and longitude populated for CreateWork history
Resolved in Pega Version 8.7
After enabling geo location in the casetype rule, when the case was created using the Create menu option from either Dev studio or Manager portal the Latitude and longitude values were set on the pxRequestor page and were available in the Case Audit history in the Map control. When the same case was created using CreateWork action configured on a button, it did not log the latitude and longitude values in the case Audit history. Investigation showed this was caused by a 'when' condition in the AddWorkHistory activity which checks the requestor page for latitude value and which had a null value when a createWork action was used to create the case. To correct this, the template metadata of the form will be populated with latitude and longitude values from pxRequestor page to be used in the latitude and longitude hidden fields.
INC-167388 · Issue 651309
Values treated as strings for offline data transform concatenate
Resolved in Pega Version 8.7
When using a Data Transform to construct a URL using multiple properties that contain values with a leading or trailing "0", the "0" was trimmed when the corresponding mobile JS code was generated using pega.process.expression.getValue("pyWorkPage.PlanData.SegmentID", "pyWorkPage.PlanData") . This was traced to the offline property type assuming that any numbers-only string should be treated as a number, so the data transform concatenate was converting “0001” to 1. To resolve this, the value will be treated as a string when being evaluated in an offline data transform.