INC-135335 · Issue 588510
Parent flow next step will take precedence over sub-process
Resolved in Pega Version 8.5.1
A Breadcrumb configured in the screen flow was not displaying at the last assignment when there were multiple embedded sub processes and the last assignment was called in a sub process. This was traced to the parent flow next step information not being passed due to the next step in the sub process being marked as an end shape. To resolve this, the pzFlowSteps7 html control has been updated to pass the parent flow's next step information in this situation.
SR-D77719 · Issue 569769
OpenIfStale updated to resolve optimistic locking race condition
Resolved in Pega Version 8.5.1
A race condition was created in optimistic locking by having two assignments save at overlapping times. This has been resolved by modifying the pzShowConflicts activity to use a version of openIfStale which will consider a workpage as stale even if the difference in pxUpdateDatetime is in milliseconds.
INC-134912 · Issue 581326
Handling updated for wait shapes with different outgoing connector flow actions
Resolved in Pega Version 8.5.1
After configuring a flow with a wait shape that by default used the pyContinueAfterWait flow action for the outgoing connector of the wait shape refer, adding any other valid flow action resulted in the error "Action To Take must be a valid flow action for this assignment". This was due to the post-processing of the connector properties modal updating the ActionToTake value based on wait shape, so that changing the flow action on a connector caused the validation on save to fail if the ActionToTake on wait shape and the connector flow action did not match. To resolve this, the system has been modified to validate a wait shape with different flow action on the outgoing connector.
SR-D59283 · Issue 523207
Check added for WorkParty property to catch changes
Resolved in Pega Version 8.5.1
After configuring a send email shape to send email to work parties, proceeding through the flow without work parties and then triggering the send email shape and creating the Fix correspondence assignment worked as expected. If the work party details were later updated and the send email shape was triggered again for the Fix correspondence assignment, the error message "No role defined to work object" appeared. This was an issue with the handling of the email flow the second time through: PyCorrPage.pyCorrPartyRole did not have the work object party details which were added to the work object after the fix correspondence assignment was created, and SendSimpleEmail was not designed to handle the email that needs to be retried during the FixCorrespondence flow call. To resolve this, the system will check whether the pyWorkParty property exists prior to calling the PartyCorrPreferences HTML rule.
INC-136208 · Issue 585226
Case history filter added for manual instantiation of Child Case
Resolved in Pega Version 8.5.1
After upgrade from v7.4 to v8.3, creating any child case from a parent case unexpectedly added the audit history "Child case xxxxx has been manually instantiated" to the parent case. In order to make this customizable, an "isHistoryAvailable" function has been added in the 'when' condition of "AddCoveredWork" Activity's "History-Add" Step. This will use the FilterHistory decision tree, which now has a setting for "ChildCaseInsAudit" to control whether or not the manual Instantiation of a Child Case will appear in the case history. The default is "true"; setting it to "false" will suppress the message.
INC-133615 · Issue 581400
Rendering corrected for contextual prompt in Case Type
Resolved in Pega Version 8.5.1
In Case Type with multiple stages, clicking to add step->More at the last stage caused the More menu to be distorted and not usable. Investigation showed that whenever the contextual prompt was opened in this way and the layout had no space on the right side, it shifted left and moved beyond the visible layout. This was traced to the two column layout in pxContextualPromptWithPreview having display styling set to block, and has been resolved by updating this setting to display as table.
INC-132297 · Issue 583956
FlowAction HelpText retained on refresh
Resolved in Pega Version 8.5.1
When a FlowAction configured with HTML was rendered on UI, reloading made the HelpText disappear. Flow action help icon is displayed using pzActionHelp control, which uses the Task Index parameter to determine whether to show the help icon or not. Investigation showed that when pyCaseActionAreaHeader was getting refreshed, this parameter was missed. To resolve this, the pzActionHelp control has been modified to fetch the correct action and index which will be used in displaying the flow action help.
INC-135751 · Issue 587287
Null check added for embedded section pyInclude tag
Resolved in Pega Version 8.5.1
When attempting to implement a call to the Pega API casetypes endpoint, the end point /casetypes/{id} returned data for only some of the casetype IDs. For others there was no content in the response and in the logs the error "null at com.pegarules.generated.pzAPICreateJsonForGroup" was seen. This was traced to the use of an old section which did not generate the embedded section pyInclude tag. When the API was called on the same section, it tried to perform an equality check on the variable which gets the pyInclude value, and the null value caused the null-pointer exception. This has been resolved by adding a null check to cover pyInclude in an embedded section.
INC-129443 · Issue 582612
Reopen details correctly saved to pxResolveSummary
Resolved in Pega Version 8.5.1
When cases were reopened using a call to the out-of-the-box Work-.Reopen activity or the Re-open work item link in the Case Tools, the changes to track the reopen in pxResolveSummary were not saved and were lost after a refresh of the case. This has been resolved by updating the ticket handling and modifying the reopenworkobject activity to set the resolve-summary details before re-opening the WO.
INC-129533 · Issue 576661
Proper MIME type kept for attachments
Resolved in Pega Version 8.5.1
When Email Listeners processed an email with an attachment and stored that attachment to an instance of DATA-WORKATTACH-FILE, it did not keep the full MIME type in the property pyAttachMimeType, but kept just the subtype (so "application/PDF" became "PDF" and "image/jpeg" became "jpeg"). As a consequence, the MIME type could not be reconstructed correctly when the file was attached to an outbound email. While most email clients were able to reconstruct (guess) the type of the file from the filename (or, more precisely, from the extension), this did not work when the email was processed by an automated system reliant on the correctly set Content-Type header. This has been corrected by reading the mime type from data-workattach-file page and setting the content type header while constructing the multipart with this value.