SR-D83548 · Issue 544307
JMS push notification made more robust
Resolved in Pega Version 8.2.7
After creating a JMS Service to call pySendPushNotification from an activity, running it using User Context worked as expected but selecting initialize Service Context resulted in the Push notification silently failing in the context of JMS service. The JMS is used as a communication medium between legacy and Pega solutions. When the message arrives, Pega creates a new case and sends a push notification to the user, who has only 2 minutes to accept the case. Because of the urgency of timeliness in this situation, the push is sent directly from the context of the service rather than expend 30 seconds for agent processing. However, because the application was not always available to the pySendPushNotification activity (and further to API call), the push failed. In order to avoid this condition, the system has been modified to use the more widely available pxThread instead of Application when possible.
SR-D85624 · Issue 552695
Corrected browser displaying checkboxes as sliders
Resolved in Pega Version 8.2.7
Checkboxes were displaying as sliders in Microsooft internet Explorer version11.1304.17134.0 due to the browser returning Table pc 2.0. Since Pega HTML class includes tablet, .tablet related styles were getting picked up and displaying the checkboxes in tablet mode. To resolve this, a check has been added to pyIsTablet to evaluate correctly at runtime.
SR-D90279 · Issue 554390
Data sync updated for use with DeferWrite
Resolved in Pega Version 8.2.7
After update, attempting a data sync from the client mobile application worked for the first object submission, but the second object failed and stayed in the list. This was traced to finish assignments running back to back when deferWrite was enabled and svcPerformFlow failed to find the assignment. To resolve this, the assignmentHandle will be passed to the activity when calling the pzSetDeferWrite activity from FinishAssignmentActionProcessor.
SR-D91532 · Issue 556404
Resolved Clear Cache error for mobile client
Resolved in Pega Version 8.2.7
When attempting to clear local storage while logged into the Mobile Client, the error message "You need to be able to connect to the server in order to clear the storage" appeared. This was traced to the application being configured to disable a user's web session immediately after log in, and was due to the "Clear Cache" functionality failing while attempting an AJAX request to invoke the server's "pzAmIOnline" activity. While there was a workaround of using the check box "Access group requires a connection for portions of the application", this has been resolved by updating the Settings - Clear Cache functionality in order be able to detect if it's online in a different way.
INC-180233 · Issue 660577
Offline.Rulecache UI module capacity increased
Resolved in Pega Version 8.4.6
Clicking the save button on a modal window caused the application to freeze and all the buttons were disabled. This was traced to the pega.offline.rulecache UI module having a default hard limit of 500 rules. Once the hard limit was reached, the system intermittently silently refused caching additional rules depending on the amount of rules packaged or the order in which the rules are loaded to the cache. To resolve this, the system has been updated to only log a console warning once the maximum threshold is reached, allowing the application to operate normally and at the time inform about the potential impact of having too many rules in memory.
INC-181126 · Issue 663304
Signature Accept callback fires correctly in offline app
Resolved in Pega Version 8.4.6
Clicking on the Accept button in the Pega mobile signature control was not properly calling the necessary pega.ui.signature.acceptSignatureCallback method. This has been resolved by adding code for the Post Success and Failure callback on Signature accept in the offline app.
INC-183559 · Issue 664815
Handling added to process Actions chunks on multiple nodes
Resolved in Pega Version 8.4.6
If the synching of chunks to a node was interrupted, attempting to resume the remaining chunks resulted in a processing issue if the Load Balancer passed the connection to a different node than was used for the first connection. As an example, if chunks were synched to node "A" and the restarted sync saved the remaining chunks to node "B", when all chunks were synced node "B" incorrectly determined node "A" was actually doing the work and skipped the processing of the chunks on node "B". This resulted in queued chunks being left untouched. To resolve this, the logic has been updated to allow multiple nodes to process the chunks.
INC-183864 · Issue 666188
Updated RequestorInitialize to improve performance
Resolved in Pega Version 8.4.6
After updating, initial user logins were taking an excessive amount of time. This was traced to the standard rule "RequestorInitialize", and has been resolved by updating the implementation.
INC-185434 · Issue 674055
Page group property passed correctly for complex questions
Resolved in Pega Version 8.4.6
When the Pega Survey Smart shape was used to configure a list of complex set of questions using Question rules and invoked using the Survey shape, the reload system was not passing the subscript value for the Page group property pyQuestionnaire. This caused an Invalid Reference exception and displayed an error pop up for the end user. Investigation traced this to a call to RefreshList to load a section holding pyQuestionnaire(Subscript) page content which was in place as part of a legacy fix but which has since been made unnecessary due to infrastructure changes in the DOM utilities. To resolve this, the ComplexQuestionCheckboxTemplate and pzComplexQuestionCheckBoxTemplateRowDetails section rules have been updated to remove the RefreshList action on checkbox.
INC-185950 · Issue 669196
Withdraw task notification uses correct email sender
Resolved in Pega Version 8.4.6
When withdrawing a Task, the withdraw email was sent from the default email box instead of the expected Application default email box. This was traced to the 'pyTaskDeleted' (notification name for withdraw task) value not being present, which meant the system fell back to the task 'pyTaskAssigned' notification name. To resolve this, an update has been made to have pyIsPulseNotificationDefinition return true for a pyTaskDeleted notification.