SR-B57614 · Issue 322754
PegaMobile honors prompt for password check
Resolved in Pega Version 7.3.1
The Pega Mobile App option to 'Always prompt for password on start' was not saving the selected choice. This was caused by a conflict with "Do not save property data" in the persistence section of the property advanced settings, and has been fixed.
SR-B67236 · Issue 325268
Resolved infinite loop in offline app
Resolved in Pega Version 7.3.1
Pressing "Next" was causing an offline app to go into an infinite loop. This was found to be caused by two issues: there was a problem with back processing when deeply nested subprocesses were configured, and the handling was not working with a subprocess that had more than one 'from-connectors'. This has been addressed by modifying the implementation logic in process_flow.
SR-B69404 · Issue 320544
Map include enhanced with fallback "Show user location" function
Resolved in Pega Version 7.3.1
When Map was included in a section by checking the "Show user Location" option, the pxRequestor.latitude and pxRequestor.longitude options were empty in the clipboard. Also, in Microsoft Internet Explorer the user location was not shown and the default Boston location was given. This was traced to a null pum.GeolocationMarker.position in Microsoft Internet Explorer, and a fallback approach has been inserted to set the position from the existing previous value.
SR-B72669 · Issue 326687
FinishAssignment updated for offline mobile reports
Resolved in Pega Version 7.3.1
When a submitted report was saved in offline mode and then retrieved from the client store, the system seemed to only retrieve the N-1 version of the work object. Analysis showed that the call to open the object after being submitted only opened the first transaction and not the last transaction recorded for the case, and the issue was traced to Finish Assignment not saving the updated work-object to the client-store. To fix this, the system will call saveWorkAndAssignment in gotAFlow defined inside finishAssignment when "no next action".
SR-B74088 · Issue 324942
Enhancement for Optimizing Packaging during full & delta sync
Resolved in Pega Version 7.3.1
As part of an enhancement for more contextual, optimistic packaging algorithm in certain conditions, packaging can be optimized based on a setting available at the case type. For example, most Field Service applications where offline capability is heavily used don't have or need the ability to instantiate or create new cases, but rather work on existing assignments routed to the agents. Some sites have the additional constraint where the case types or the flows within a case type may be large in number and dynamically created, which means the first full sync will just not be sufficient for the user to work on later created assignments. This has an adverse impact on the performance of the full sync and the first login time. The following changes have been introduced: - On delta sync - if a new work item ( of new case type which is not there during full sync packaging ) is added to work list. All the dependent rules of this new case type will be packaged and sent to HC. Added an checkbox in the case type rule "Only offline when in user's worklist" which will be visible only when "Enable Offline" is checked. - Provided a new when rule pyPackageAssignmentFlows which is set to false by default. When the true, all the case type with "Only offline when in user's worklist" will have selective flow packaging. - Create a class structure with a page group to hold full packaging and optimized packaging Application.pyOfflineCaseTypes("full") Application.pyOfflineCaseTypes("optimized") Above properties are populated in pzGetStartingFlows activity which is ran on delta sync and full sync. - Flows that are created in the case with "Only offline when in user's worklist" check are listed in pzDataSyncGetworkList which will be packaged during delta sync. The flows are listed for packaging if there is any Work Object created, flow is retrieved from the Assignment's pzInsKey key, and Flow key is built. Changes are made in the PackageRuntime.java to iterate the flow and perform packaging.
INC-120326 · Issue 564435
Landing page refresh modified to avoid frequent reloads
Resolved in Pega Version 8.2.7
Approximately every two weeks, clients were able to login but it was not possible to work as the landing page refreshed constantly until all of the nodes were rebooted and the issue was cleared. Investigation indicated the frequent reloads were related to the cacheing of the operator details, and this has been resolved by updating the datapage reload strategy based on 'when' so frequent reloads will be avoided.
SR-D68572 · Issue 543003
Added check for duplicate attachment names with S3
Resolved in Pega Version 8.2.7
S3 Storage does not allow duplicate file names, but the AttachContent function was allowing duplicate file attachments. Due to this, the sync was failing to attach on the server and the message was never communicated to the client. This has been resolved by adding a check for duplicate file names when the storage is repository.
SR-D77580 · Issue 550093
Corrected Survey button refresh issue
Resolved in Pega Version 8.2.7
After implementing a Pega Survey question page with dynamic / reflexive questions (Answer to Question 1 determines Question 2 and so on) where every answer pick caused a refresh, picking various radio buttons quickly caused an unexpected busy indicator. Investigation showed that on click, both refresh section and run activity were executed asynchronously, triggering the property mapping refresh before answers were clicked. To correct this, the clearSelection function call in pzsurvey_ui_userscript JS file has been modified, and questionPageName has an added 'if' condition.
SR-D81500 · Issue 554903
Uploading Pulse attachments made more robust
Resolved in Pega Version 8.2.7
Upon uploading a file in the Pulse section for a case created in the Case Worker portal, the error message "File <filename> doesn't exist or is empty" appeared. This was traced to using a third-party repository when the network was slow, and has been resolved by instituting the use of callbacks/timeintervals to execute a particular function call only after getting proper results.
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.