SR-B7621 · Issue 278634
Activity created cases open correctly
Resolved in Pega Version 7.3
When a case was created through an activity, an error was generated when opening the case and clicking to open assignment. This was traced to an incorrect page name being passed if the primary page was different, and has been resolved by modifying the CompleteAssignment activity Step 19 to check the precondition of Page name.
SR-B8696 · Issue 279855
Support added for FCM GetNextWork
Resolved in Pega Version 7.3
When using Federated case management (FCM) to get next work, the work object pulled was not assigned to the operator. This was due to the implementation of FCMR not supporting the moving of workbasket assignments to worklist through get next work. To support this use, the following functions now accept extra parameters as last param: FCMRGetNextWork FCMRGetNextWorkItem FCMRProbeNextWorkItem This will enable distinguishing between normal GNW and federated GNW, and it is possible to override any py rule call MoveToWorklist.
SR-B9998 · Issue 279141
Improved handling for apostrophe in email addresses
Resolved in Pega Version 7.3
In order to improve mail handling, the system will now only remove the the starting and ending apostrophe in an Email address and will not strip apostrophes in the middle of an address.
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.
SR-B57619 · Issue 316602
Bulk processing actions list corrected
Resolved in Pega Version 7.3.1
Even though the filter condition contained 'Assigned to Workbasket', the action list on selected assignments contained action for work objects. This was caused by a defect in the @baseclass.pyGetRelevantActions activity which would conditionally set local.bAssignmentChosen; this setting is not necessary, and the conditional setting has been modified to be 'true'.
SR-B53374 · Issue 312278
Bulk actions RD templates can be overridden
Resolved in Pega Version 7.3.1
Even though the pyBulkProcessingTemplate RDs in the application class were overridden, the RDs in Work- were being picked at runtime. This was because in pzRunBulkProcessReport, the class of RD is hardcoded to Work- while opening the RD. To resolve this, the hardcoding has been removed and instead the workpool class will be passed as the pyClassName while opening the template RD.