INC-190222 · Issue 675955
Emails load with PegaRULES:User4 access
Resolved in Pega Version 8.7
Operators with access groups under PegaRULES:User4 were unable to access emails. This was found to be a side effect of Access Control (BAC): if Production level was set to >=4 then the email body could not be seen in the Email Manager Portal and console reported a 403 Forbidden error. To resolve this, the open work by handle action has been added to the Allow List.
INC-190417 · Issue 675213
ModifiedGetEmailPosts data transform to better handle very large messages
Resolved in Pega Version 8.7
Blank emails were seen when the message was over 4000 characters. This was traced to an issue with initializing param.index2, and has been resolved by modifying the pxGetEmailPosts data transform to take param.index2=0 out of the loop for large emails.
INC-191159 · Issue 682362
Validate topics based on all topics in channel instead of default language
Resolved in Pega Version 8.7
if a 'When Rule' was used in Email Receiver to provide some conditions, it was not possible to use topics from the dropdown which were trained with training data in prediction studio. This was a missed use case, and was traced to validation being based on the default language topics. To resolve this, the data page has been modified from getting default language topics to getting a union of topics. The datapage for default language topics has also been withdrawn.
INC-192646 · Issue 679065
Correct class for properties set by Chatbot
Resolved in Pega Version 8.7
After initiating a service case from legacy webchat and subsequently resolving the case using DX API V1, additional properties with a different applied-to class than that of the workclass were added to the service case workpage while setting answer values to the question structure from the @baseclass.pxSupplyAnswerToQuestion API. Open assignments on the case could be submitted through the portal without any issues but validation errors occurred when the same assignment was completed though DX API, e.g. from a custom React frontend. This has been resolved by moving the properties to baseclass or Work- class as appropriate.
INC-193727 · Issue 679111
Entity mapping order updated for email bot
Resolved in Pega Version 8.7
Issues were seen with the entity mapping functionality in Email bot, especially when mapping email headers like subject, from (email) etc. to case properties. This was an issue with the order in which the entities were mapped ,and has been resolved with an update that will map entities which are configured in the channel first and then mapping the rest.
INC-195354 · Issue 682183
Handling updated for UpgradeBeforeOpening
Resolved in Pega Version 8.7
After update, an email case paused for 1 minute with a wait shape and then resumed by a ServiceLevelEvents agent seemed to lose the context (class) of the case and went into the broken processes queue with the error "Unable to open an instance using the given inputs: pxObjClass = "Work-Channel-Triage"". This was traced to an incorrect class applied by the activity OpenAndLockWork which assumed that "Work-Channel-Triage" was the preferred class and passed in the case ID as a parameter. To resolve this, pzUpgradeBeforeOpening has been updated such that it will migrate a case only if it has "WORK-CHANNEL-TRIAGE" in the work object inskey.
INC-196389 · Issue 690786
ConfigurationReconciliationTask updated for greater compatibility
Resolved in Pega Version 8.7
After updating from Pega 8.3 to Pega 8.6, models which previously had learning and performance AUC greater than 0.7 reported an AUC of 0.5. This was traced to the update handling in ConfigurationReconciliationTask. AdmRuleBrowser does not perform ruleset resolution, so all rules were returned, for example the rule for model A in both the 08-01 and 08-03 ruleset. The system then iterated over all of the adaptive model rules returned by AdmRuleBrowser in order to assess whether a configuration update was necessary. The condition to update the model rule was met when either the config key did not exist (indicating a newly added configuration) or the model rule was "old" (version <2). For models generated in Pega 8.3 or earlier the version number for all rules must be 1, and the update to Pega 8.6 therefore caused the ConfigurationReconciliationTask to be applied to all adaptive model rules. To resolve this, the configuration update check in ConfigurationReconciliationTask has been removed.
INC-196623 · Issue 686131
Chatbot outbound message formatting corrected
Resolved in Pega Version 8.7
Chatbot outbound responses were displaying appended br tags for next line in the messages. This was due to a formatting error in the menu (message type) title, and has been corrected.
INC-197116 · Issue 684955
Handling updated for migrated cases
Resolved in Pega Version 8.7
When performing a contact search in an interaction case that was migrated from an earlier version, clicking the Add Task button generated an exception when executing pzSendFeedbackToNLP(step 9) > pzFindTopicModel. This was traced to an unnecessarily call to pzMigrateInteractionCases each time a migrated case was opened, and has been resolved by updating the system to use JumpToLaterStep in Step1 of pzCheckAndMigrateInteractionCases to avoid calling MigrateCase again.
INC-201334 · Issue 690735
ADMinputsource field population updated to handle transactional decisions
Resolved in Pega Version 8.7
The CaptureResponse flow was failing while writing to AdaptiveAnalytics with the error "IllegalArgumentException - argument does not represent JSON object". This occurred while running an outbound campaign where a few decisions were treated as transactional and did not have Model executions. Attempting to set a response for these decisions resulted in a JSON parse exception being thrown due to pxADMInputs not being populated (no models executed). This occurred only when using transactional actions in CDH, and was caused by the system only including predictive models during the make decision flow due to common inputs not being stored. While there was a workaround of overriding the property pzADMInputSource to use modelReferences instead of admInputContainer, this has been resolved by correcting how the pzADMinputsource field is populated. When there is no modelInput, the system will not populate that field so the page is ignored.