SR-D86200 · Issue 549034
Resolved tab appearance issues related to resolution support
Resolved in Pega Version 8.4.1
When trying to add multiple tabs on larger screens, once the first row was filled with tabs then new tabs began appearing at the bottom of the layout group. The layout group worked as expected with the tab overflow having the right and left arrows with the dropdown on smaller screens. In addition, @1440px the overflow arrow on the right side was not working correctly, showing as grayed out even though focus was not on the last tab. These issues were traced to taboverflow with add icon not working correctly at certain resolutions. To resolve this, the todisableslide function has been updated to consider add icon width and layoutgroup has been updated to consider parent width.
INC-170721 · Issue 658960
Stricter criteria set for reusing an SSAExecutionContext
Resolved in Pega Version 8.7
After a Strategy was configured with an existing Proposition Filter and the Explain Results box was unchecked, executing the strategy resulted in the error "Stack is empty, cannot pop any more frames". Investigation showed that the SSAExecutionContext object was reused across the two criteria evaluation in Proposition Filter rule: this works well as long as the input is the same across the two evaluations. However, the SSAExecutionContext object also stashed a reference to a PublicAPI object which became stale in the second evaluation and caused the empty stack issue for the given scenario. This has been resolved by providing stricter criteria in deciding when an SSAExecutionContext can be reused or not in the case of Proposition Filter rule.
INC-187103 · Issue 671737
Guided Tour working from Actions menu
Resolved in Pega Version 8.7
After updating from Pega 8.4 to Pega 8.5, "Manage a Guided Tour" was no longer working under a local action when called from the Actions menu on a work object. An unspecified error message appeared in the tracer. Investigation showed there was a null pointer error caused by the menu being invoked on an invalid page, and this was traced to updated authentication requirements: registration at the portal is not reliable as it is thread-scoped and run only once. The thread name is not guaranteed to stay the same so subsequent invocations of the tour activities failed. This has been resolved by modifying the call registration function to handle the security issues related to the generation of the menu path.
INC-199303 · Issue 690629
Guided Tour working from Actions menu
Resolved in Pega Version 8.7
After updating from Pega 8.4 to Pega 8.5, "Manage a Guided Tour" was no longer working under a local action when called from the Actions menu on a work object. An unspecified error message appeared in the tracer. Investigation showed there was a null pointer error caused by the menu being invoked on an invalid page, and this was traced to updated authentication requirements: registration at the portal is not reliable as it is thread-scoped and run only once. The thread name is not guaranteed to stay the same so subsequent invocations of the tour activities failed. This has been resolved by modifying the call registration function to handle the security issues related to the generation of the menu path.
INC-191756 · Issue 718549
Corrected dashboard focus highlighting
Resolved in Pega Version 8.8
Dashboard links like "My activities"/"My cases"/"Recent"/"Search” were displayed with a yellow focus highlight even though the user was not currently in those screens. Investigation showed the data-menu-id for control_menu was being appended with the workid until selecting another tab caused it to reset to its original value without workid. This change in menu-id was responsible for the issue with focus, and occurred only when render as single checkbox was unchecked. This has been resolved by removing workid from menuid and adding a unique id for the outside menu and inside case same menu.
SR-D84795 · Issue 546204
Handling added for NOT NULL primary key requirement
Resolved in Pega Version 8.4.1
The CRMFS application upgrade failed during an upgrade of a Production-clone environment to Pega 8.3.1 with the error "Encountered an issue applying DDL: ALTER TABLE pegadata.pr_History_PegaSAFS_Data_ReasonCode ALTER COLUMN pzinskey DROP NOT NULL: Database-General Problem executing SQL to update database schema ERROR: column "pzinskey" is in a primary key." This occurred because the database had a table column as primary key with a NOT NULL modifier while the archive that needed to be imported had a table column with neither the primary key nor NOT NULL modifier in it. Therefore during import the system was trying to drop the NOT NULL modifier first, resulting in the error as NOT NULL cannot be removed if it is a primary key. To resolve this, handling has been added for the use case of not dropping the NOT NULL requirement for the primary key.
INC-182776 · Issue 666941
CheckFlowDependencies updated for auto-instantiated child cases
Resolved in Pega Version 8.7
A parent case with more than one child case was producing an unexpected behavior during the child case creation process. The first child case was instantiated at the correct point of the case stage based on its dependency condition, but the following cases were instantiated at the same point where the first child case was created irrespective of the dependency conditions defined in the other child cases. Investigation showed that the pxCheckFlowDependencies activity called from the Resolve activity was removing the named pages "pyTopCaseMap" "pyTopCaseWork" which are required for starting and validating configured auto-instantiate child cases in the pzCanStart function. To resolve this, an update has been made to CheckFlowDependencies which will use the activity "pzResolveCaseHierarchyMap" for removing the "pyTopCaseMap" and "pyTopCaseWork" pages based on DependencyType.
INC-190070 · Issue 676643
Restored local blocking queue cache
Resolved in Pega Version 8.7
After update, it was not possible to bring up secondary VBD nodes after restarting. Investigation traced this to earlier work done to resolve a memory leak issue, in which stale entries for local blocking queues were removed from cache. This resulted in modifying the queue listener logic to use "cache.getQueueIfPresent(jobId)" instead of "cache.getQueue(jobId)". Because the listener was not creating the cache if it was not present and the cache which held the local blocking queue didn't have the entry for the current remote execution job ID, the caller of the remote execution on Node2 ended up in blocking state forever, waiting on the local blocking queue. To resolve this, the code has been updated to ensure the blocking queue is created and stored in the local queue cache before publishing the remote job message.
INC-193153 · Issue 686293
Restored local blocking queue cache
Resolved in Pega Version 8.7
After update, it was not possible to bring up secondary VBD nodes after restarting. Investigation traced this to earlier work done to resolve a memory leak issue, in which stale entries for local blocking queues were removed from cache. This resulted in modifying the queue listener logic to use "cache.getQueueIfPresent(jobId)" instead of "cache.getQueue(jobId)". Because the listener was not creating the cache if it was not present and the cache which held the local blocking queue didn't have the entry for the current remote execution job ID, the caller of the remote execution on Node2 ended up in blocking state forever, waiting on the local blocking queue. To resolve this, the code has been updated to ensure the blocking queue is created and stored in the local queue cache before publishing the remote job message.
INC-201338 · Issue 690896
Restored local blocking queue cache
Resolved in Pega Version 8.7
After update, it was not possible to bring up secondary VBD nodes after restarting. Investigation traced this to earlier work done to resolve a memory leak issue, in which stale entries for local blocking queues were removed from cache. This resulted in modifying the queue listener logic to use "cache.getQueueIfPresent(jobId)" instead of "cache.getQueue(jobId)". Because the listener was not creating the cache if it was not present and the cache which held the local blocking queue didn't have the entry for the current remote execution job ID, the caller of the remote execution on Node2 ended up in blocking state forever, waiting on the local blocking queue. To resolve this, the code has been updated to ensure the blocking queue is created and stored in the local queue cache before publishing the remote job message.