SR-D5904 · Issue 490489
Discard changes dialog now showing for local actions
Resolved in Pega Version 8.1.7
After having modified case data without saving and clicking on a menu entry (left menu, search, ...), the system shows a dialog box to ask the user to confirm it is ok to discard changes. However, this confirmation dialog did not work with local actions, leading users to lose their work without any warning nor any way to step back. This was traced to a difference in the dirty form check, which was not present when launching a local action from a case. An enhancement has now been added to the handleMenuAction js function in pypega_ui_harnessactions.js which will perform a dirty form check with a prompt.
SR-D23723 · Issue 503090
pxGenerateExcelFile updated for handling blank dates
Resolved in Pega Version 8.1.7
When using a custom template for exporting to Excel, blank DateTime property column values defaulted to the current date. To resolve this, the pxGenerateExcelFile activity has been updated to ensure that an empty date will be exported as blank and that given dates will appear in the correct datetime format.
SR-D24950 · Issue 494566
Added explicit step page to resolve null-pointer exception with custom error message
Resolved in Pega Version 8.1.7
A null pointer exception was generated during case run time harness refresh after a custom error message was inserted. This was traced to a blank step page related to the custom message, and has been resolved by adding a primary step page at step 10 of the New(Work-) activity to prevent the null-pointer exception on harness reload.
SR-D42679 · Issue 509565
oLog.infoForced has been replaced with oLog.debug in GetAssignmentDetailsInternal to reduce excessive logging
Resolved in Pega Version 8.1.7
The Rest API used by Robotics was generating excessive logging on the application server due toPzGetAssignmentDetailsInternal generating several lines of logs with each REST call. In a high volume system, this can make the logs difficult to utilize. To resolve this, oLog.infoForced has been replaced with oLog.debug.
SR-A5412 · Issue 219159
Error marking fixed for TreeNavigation7 screen flow
Resolved in Pega Version 7.3.1
When using the TreeNavigation7 harness in the screen flow to call the validation from the post action, any property error in any of the flow-actions caused only the first flowaction to be marked as having an error while the rest were marked as successful. This has been fixed.
SR-B64971 · Issue 315219
Added alt text attribute to paperclip icon for accessibility
Resolved in Pega Version 7.3.1
A paperclip icon in the pzMultiDragDropControlStandard rule did not have alternative text, impacting its accessibility. An alt="" attribute has been added to the image tag to correct this.
SR-B51367 · Issue 311023
Resolved stack overflow for three level nested WO
Resolved in Pega Version 7.3.1
A StackOverflow exception was generated when using three levels of nested work objects due to a recursive looping of the parent pzInskey looking for its children. To fix this, the pyLoadMyCasesNested activity has been updated to set the RD based on whether a parameter sent to it is blank.
SR-B58009 · Issue 312838
Updated removeAssignment call for Assign- class
Resolved in Pega Version 7.3.1
After upgrade, some cases were becoming corrupted with the error "trying to calculate the handle of an instance may not be written to Database". This was traced to an unnecessary removeAssignment call to the ProCom flow library when work objects class is of Assign- ; this is old and has references to named pages like newAssignPage which may be empty. To correct this, the call to pega_procom_flow.RemoveAssignment has been replaced with pega_processengine_flowutilities.RemoveAssignment.
SR-B64353 · Issue 313990
Resolved assignment error when competing with SLA
Resolved in Pega Version 7.3.1
An Assignment error was occurring when the SLA competed with the user for an assignment. This was an error with setting the success indicator in the EstablishContext Activity, and has been fixed.
SR-B53049 · Issue 311589
SLA agent honors custom case type time-out
Resolved in Pega Version 7.3.1
Despite an assignment having a 3-hour lock period, the SLA agent was able to advance the assignment and remove access if the goal/deadline passed in less than that lock period. This was caused by a handling error where the order of steps led to not honoring custom timeout mentioned in the case type. This has been fixed.