SR-119055 · Issue 174515
Corrected drop-down onchange event firing for accessibility mode
Resolved in Pega Version Pega Platform, Resolved in Pega Version 7.1.7
If a select button was associated to a DynamicSelect control in a Cascading Dynamic Select configuration with WAI, at runtime, the child DynamicSelect list was auto loaded once the value on the parent DynamicSelect list was changed. In accessibility cases, the select button was introduced to be beside the drop down to set the value selected from the drop down. However, in cascading dynamic select, selecting the value from first drop down caused the values in the second drop down to load because an onchange event was fired. In order to handle this correctly, pega_ui_dynamicselect js has been updated to not fire upon change event when in accessibility mode, but instead fire upon click of the select button.
INC-139966 · Issue 606842
JAWS announces popup error message
Resolved in Pega Version 8.6
When a form is submitted without giving value to required field, a browser pop up appears. The expected behavior is that the screen reader (JAWS) should move the focus to the field that has error and read the error message However, JAWS was not announcing the error "Value cannot be blank". This was traced to a scenario where if pega.u.d.fieldErrorType === "ERRORTEXT" is true, the class on the span within the error div will be set to "inputSpans", and this resulted in the return of an empty array for document.querySelectorAll("span.iconError.dynamic-icon-error"). To resolve this, support has been added for the "inputSpans" class.
INC-150072 · Issue 621295
Section Include error handling updated
Resolved in Pega Version 8.6
When trying to add or include a section in the design template mode of a section rule or during run time of the application, the error "java.lang.StringIndexOutOfBoundsException: String index out of range: -1" was generated. Investigation showed this was originating from the SectionIncludeForm_Post activity of the class Rule-File-Form, and was traced to a system error related to the 'if' condition which verifies the circular reference of the section being newly added. Because this was a system error and not one generated by Pega, there was no handling for it. To resolve this, the sectionincludepost activity in rule-form class has been updated to determine the source and properly handle the error messages.
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-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.