INC-184964 · Issue 705933
TextMask_Encrypted rule added for use with Oracle
Resolved in Pega Version 8.7.2
When a property was being encrypted by propertyEncrypt access control policy and masked by propertyRead access control policy, it showed a "@@getMaskedValueOfText" error. This has been resolved with the addition of a new rule pxTextMask_Encrypted for Oracle product type which will remove extra spaces from the SOURCE string to handle ORACLE specific usecases.
INC-209387 · Issue 706151
Security updates
Resolved in Pega Version 8.7.2
Security updates have been made relating to rulesets using allow lists, checks for Java code injections, SAML-based SSO code, and supporting SFTP as part of the validation in the pxValidateURL rule.
INC-200030 · Issue 719228
Handling added for external Kafka authorization exception
Resolved in Pega Version 8.7.2
When using external Kafka for stream service, the dataflow was failing with the error 'QueueProcessorDataSubscriberException' when topic create permission was missing. As a workaround, the topics could be pre-created, though a "Topic already exists" warning was generated. To resolve this, the cluster-wide right that a producer needs, IdempotentWrite, has been added. For more information please refer to the link https://docs.confluent.io/platform/current/kafka/authorization.html
INC-202793 · Issue 698506
Corrected malformed URL
Resolved in Pega Version 8.7.2
The function used in the session timer to log off the user was not working consistently, and attempting to discard a checked-out delegated Rule did discard the rule. Both issues reported the error "HTTP Status 400 - Bad request". This was traced to a badly formed URL, and has been resolved by wrapping the URL with SafeURL_createFromURL.
INC-207307 · Issue 709715
Corrected OAuth jar version for custom Keystore rule
Resolved in Pega Version 8.7.2
Attempting to create a custom JKS and Keystore rule so it could be pointed to the Pega cipher and use the encrypt and decrypt functionalities failed with an error indicating it was not a valid KMS keystore. This was traced to an issue with a jar version mismatch: upon checking the dependencies for the nimbus-oauth-sdk jar, even though version 6.18.1 was specified the system picked the 8.27 version through transitive dependencies, and the 8.27 version doesn't have the needed CommonContentTypes class. This has been resolved by reducing the version to 6.18.1 in conflicting build.gradle.
INC-213610 · Issue 708114
Job Scheduler explicitly unlocked after nodes restart
Resolved in Pega Version 8.7.2
If a job scheduler was in running state and the utility nodes were restarted, the background processing nodes were not coming up and resuming as expected and PersistentJobCleanupFactory:PresentMembersJobCleanup was throwing a stale execution exception. Investigation showed locks were not being removed from the database for the job scheduler when the restart was performed (noted in pegadata.pr_sys_locks table), preventing further runs. This has been resolved by adding an explicit lock removal process for this condition.
INC-213763 · Issue 708110
Job Scheduler explicitly unlocked after nodes restart
Resolved in Pega Version 8.7.2
If a job scheduler was in running state and the utility nodes were restarted, the background processing nodes were not coming up and resuming as expected and PersistentJobCleanupFactory:PresentMembersJobCleanup was throwing a stale execution exception. Investigation showed locks were not being removed from the database for the job scheduler when the restart was performed (noted in pegadata.pr_sys_locks table), preventing further runs. This has been resolved by adding an explicit lock removal process for this condition.
INC-210346 · Issue 709711
Check added to ensure Job scheduler executed only once
Resolved in Pega Version 8.7.2
When Node A and Node B woke up at the same time to start executing the job scheduler, both were attempting to update the "now processing" node ID with their ID but only Node A succeeded. This caused Node B to generate a "lock already held" exception, then Node B would try to release the lock and update "now processing" node ID. If Node A released the lock before Node B tried to, then Node B updated the "now processing" nodeID and executed the scheduler, causing it to be run twice. This double-run has been resolved by adding a check for whether the job scheduler has been executed recently before starting it.