INC-196313 · Issue 688605
Added pause after Library Extraction to ensure Rule-Utility-Functions are present
Resolved in Pega Version 8.7
After upgrade from Pega 7 to Pega 8, nodes were not starting and the error "pub.context.InitializationFailedError: PRNodeImpl init failed" appeared. This was traced to an issue with the pzSharedTenant rule: when pzSharedTenant (Rule Access When) is assembled by the system, it uses the compareTwoValues Rule-Utility-Function. If the system is not able to find the correct version of compareTwoValues, it adds an UnresolvedAssemblyError in the assembly of the pzSharedTenant, causing the startup failure. This has been resolved by adding an await call after the LibraryExtraction task to wait for it to complete. This wait will ensure that the library extraction task completes before starting the search task which uses Rule-Utility-Functions
INC-196604 · Issue 686005
New or updated operators properly updated on other nodes
Resolved in Pega Version 8.7
Newly imported or updated operators were not getting properly pulsed to other nodes. This was traced to operator pages being cached while the system pulse for 'Data-Admin-Operator-ID' was not permitted on the allow list, and has been resolved.
INC-197112 · Issue 689260
Corrected unnecessary Severe Warnings for MSGraph account
Resolved in Pega Version 8.7
After configuring an email account with MSGraph settings and saving the the email account instance, three unneeded severe guardrail warnings were generated related to using D_pxGetApplicationSettingValue instead of a constant value. This has been resolved.
INC-198632 · Issue 687582
Handling added to correct class setting during DX-API
Resolved in Pega Version 8.7
When a DX-API call was made (assignments/{ID}/actions/{actionID}/refresh) the ApplyPageInstructions activity was updating the case with an incorrect class, causing the rules from the wrong class to be picked and blocking the case progression. This has been resolved by setting the proper parameter Param.workPage while calling pzApplyPageInstructions from pzUpdateCaseWithRequestBody to calculate the proper class for the content.
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-
184212 · Issue 677286
Updated AgentName handling for QueueItemID
Resolved in Pega Version 8.6.4
A report was showing as scheduled but no mail was received when it was supposed to run. Investigation showed this was due to the reports being corrupted, leading to the flow skipping the necessary Queue-For-Agent method. While there was a workaround of doing a "Save As" to create a new version of the report, this has been addressed by setting the agentName before saving to the database to handle missing agentName cases and ensure pyAgentname is always populated when pzQueueItemID is not empty.
INC-195586 · Issue 698861
Updated access group handling for CurrentWorkPool property
Resolved in Pega Version 8.6.4
After update, the pxThread.pxCurrentWorkPool property was not properly populated in App Requestors when the activity was called from Rest service. This was caused by a difference in the authentication check after a security modification, and has been resolved.
INC-197479 · Issue 695025
ClusterAndDBCleaner updated to with with Oracle query limits
Resolved in Pega Version 8.6.4
The pzClusterAndDBCleaner job scheduler was not able to cleanup data in pr_op_data session table due to the delete query formed to clean up this table throwing "ora-01795 maximum number of expressions in a list is 1000 oracle 19c" exception. This has been resolved by splitting requestor IDs into batches of 1000.
INC-197964 · Issue 707875
Engine updated to default to hard references in cache
Resolved in Pega Version 8.6.4
A scheduled campaign executing at midnight was failing with a null pointer error message. Rerunning the same campaign during the day did not encounter any issues. Investigation showed there was a race condition that occurred under heavy load and parallel executions which caused soft references to be garbage collected while a thread was accessing the same soft references. This has been resolved by updating the following DSS so the system will default to using hard references: Ruleset: Pega-Engine Purpose: prconfig/cache/enablesoftreferences/default Value: false
INC-199076 · Issue 703301
Revalidate of class rules successful after major version skimming
Resolved in Pega Version 8.6.4
When performing a major ruleset version skim and revalidating all rules, most class rules were failing during the revalidation. This was a gap in how Ruleset List and Major Version Skim work together. When calling getRuleSetPrerequisites(“rulesetA:01-01-01”), the API uses uses the current application context to return a ruleset list from an application which owns rulesetA and its compatible version, but if no owning application was found from the current application context, a list of rulesetA and PegaRULES:XX-XX-XX was returned. This caused a conflict between what the system was trying to validate and the ruleset versions returned. To resolve this, an update has been made which will exclude the version number for this comparison if no owning application is found.