Merative ™ Social Program Management 7.0.7.0 Refresh Pack

Release Notes

Abstract

Merative Social Program Management 7.0.7.0 Refresh Pack Release Notes

Content

Important Note
Introduction
System Requirements
Download
Installation
Improvements, Resolved Issues and Third Party Updates
Known Issues
Notices

Important Note

Merative Social Program Management 7.0.7.0 is a Refresh Pack.

Introduction

Welcome to the Merative Social Program Management 7.0.7.0 Refresh Pack release. Read this document to find important installation information, and to learn about product improvements and resolved issues in this release.

This 7.0.7.0 Refresh Pack release also includes optional new Enhanced Universal Access functionality.

For detailed information about these optional new features, see the What's new in Version 7.0.7.0 topic in the product documentation.

For more information about version 7.0.7.0 Refresh Pack, see the full product documentation in Product documentation and PDFs.

For the latest version of the release notes, see https://curam-spm-devops.github.io/wh-support-docs/spm/release-notes.

A CSV file is attached at the end of this document, which summarizes these release notes.

This 7.0.7.0 Refresh Pack release incorporates content from previous 7.0.X releases, which is documented separately in the following set of online release notes:

• Merative Social Program Management 7.0.6.0 Refresh Pack

System Requirements

For information about the supported software and hardware for this release, see the Merative Social Program Management Prerequisites.

Download

See the download instructions for this release at /support/curam.

Installation

Before running the installer please ensure all files in your Merative Social Program Management installation are writable.

The installation steps are as follows:

• Extract the contents of the .zip file to a local drive location.
• Run the Merative Social Program Management installer, which can be found in the INSTALLER folder at that location.
• After installing, the appropriate build targets must be run as necessary for your installation.

Additional installation instructions can be found in the Development Environment Installation Guide.

Upgrading

If you are upgrading from a previous version, the Merative Social Program Management Upgrade Helper contains documentation and tooling to help you to upgrade your Merative Social Program Management application codebase and database to work with your new version of Merative Social Program Management. The Merative Social Program Management Upgrade Guide describes a recommended process for performing application and database upgrades. The Upgrade Helper contains tools to assist you with implementing the upgrade, including tooling to produce a schedule of required migrations for your upgrade, tooling to provide information about database schema changes and tooling to generate initial SQL scripts for applying changes to your database.

To download the appropriate version of the Merative Social Program Management Upgrade Helper, see the download instructions at /support/spm.

Improvements, Resolved Issues and Third Party Updates

Third Party Updates

WorkItem:246015 - Upgrade the version of Google Guava to 27.0.1-jre and add failureaccess-1.0.1.jar

Google Guava is an open source set of core libraries for the Java platform released by Google under the Apache License. The version of Google Guava used in the Social Program Management (SPM) product has been updated from 19.0 to 27.0.1-jre. This update involved changes to the following JARs delivered as part of the Server Java Development Environment:

• guava.jar (updated from 19.0 to 27.0.1-jre).
• failureaccess-1.0.1.jar - this is a new JAR that has been introduced into the SPM deliverable. This is as a result of the refactoring of the existing guava.jar which now depends on this new JAR.

Note that if there are references to the guava.jar in custom build scripts and/or classpaths, these should now be updated to include a reference to the new failureaccess-1.0.1.jar file.

WorkItem:248127 - Browser Support Update

The following browser versions have been updated and certified for this release:

Case Worker Application Browser Support

• Google Chrome updated to 75

Universal Access Application Browser Support

• Google Chrome updated to 75
• Mozilla Firefox updated to 67

WorkItem:248130 - Update Browser Plugins JRE levels used in Microsoft Word Integration

The following JRE level for Word Integration is supported for this release:

• JRE 1.8 u211

Cúram Enterprise Framework

PO08138, WorkItem:243895 - A deleted attachment can be downloaded from the Edit Attachment modal

Issue Description:

A deleted attachment can be downloaded from the Edit Attachment modal.

User Interface Impact: No

Steps to Reproduce:

1. Login as a caseworker.
2. Select Register Person and Create Case under Cases in the shortcuts panel.
3. Enter the Person details and select any case from the Type drop-down.
4. From the case home page, select Contact and then Attachments.
5. Click New to create a new attachment.
6. Browse for a File and add the mandatory Description.
7. Click Save.
8. Select the row level menu Delete for the newly created attachment.
9. Answer Yes on the Delete Attachment modal.
10. Select the row level menu Edit to update the deleted attachment.
11. Issue: The information in the Name field still shows a link for the filename.

Resolution:

The Edit Attachment modal has been updated so that if the status of the attachment is Canceled, the filename in the Attached File field is shown as normal text and not as a link.
Technical:

The following page has been updated to only show the filename as text if the attachment has been canceled:

• Case_modifyAttachmentView1.vim

PO07686, WorkItem:246095 - When selecting a link inside of an inline page that opens a new tab, the page in the content panel does not open correctly

Issue Description:

When selecting a link inside of an inline page that opens a new tab, the page in the content panel does not open correctly.

User Interface Impact: Yes

Steps to Reproduce:

1. Login as a caseworker.
2. Register a new Person.
3. Register a second Person.
4. From the second Person, click on the Administration tab.
5. Select Duplicates and click on the Mark New Duplicate page level action.
6. Search for the first Person.
7. From the search results click the Select link to navigate to the Mark Duplicate page.
8. Click Save.
9. From the Administration tab on the second Person, select Duplicates.
10. Use the toggle to drill into the duplicate person record in the list.
11. Now click on either the Original or Duplicate name.
12. Issue: The Person home page opens, but the Add Picture and Remove Picture buttons are displayed centrally at the top of the page.

Resolution:

The link tag renderer has been updated to reset the screen context to allow the correct display of the home page.

PO08307, WorkItem:247731 - The description of the system property 'curam.miscapp.middleinitial.enabled' is unclear

Issue Description:

The description provided for the system property 'curam.miscapp.middleinitial.enabled' is unclear. It states that this property governs whether or not the middle initial of a participant's name appears in lists. More specifically, this property governs the behaviour in drop-down fields and this should be reflected in the description to avoid confusion.

User Interface Impact: No

Steps to Reproduce:

1. Login as a system administrator.
2. Click on the System Configurations tab.
3. Click on Property Administration under Application Data in the shortcuts panel.
4. Enter the property in the Name field and click Search.
5. Click on the toggle of the row returned to view the description.
6. Issue: The description says that the property governs whether or not the middle initial of a participant's name appears in lists.

Resolution:

The property description has been updated to read 'Enabling this property will trigger the middle initial being displayed for a person in case member/participant drop-down fields'.

Integrated Case Management

EVIDENCE MANAGEMENT

PO08199, WorkItem:245106 - A person's deleted Email Address continues to display in the context panel of the Person home page

Issue Description:

When an email address is deleted from the evidence listing for a person, the context panel still reflects the removed email address as a way of contacting the person.

User Interface Impact: Yes

Steps to Reproduce:

1. Login as a caseworker.
2. Register a new Person.
3. Click on the Evidence tab and use the action menu to capture an Email Address for the person.
4. Once captured, check the context panel to ensure that this Email Address is displayed.
5. Delete the Email Address.
6. Issue: The reloaded Person home page continues to display the deleted Email Address in the context panel.

Resolution:

This issue was due to a database query that did not perform any checks on the email address status. The resolution involved the creation of a new database query which returns the email address only if it is active.
When a person's email address is deleted, the context panel now shows the message Not Recorded instead of the deleted email address.

PO08255, WorkItem:246581 - The Evidence Generator for static evidence is not fully qualifying attributes in some of the generated pages which can potentially lead to client build problems

Issue Description:

Attributes are not fully qualified in certain pages that are generated using the Evidence Generator, which is used to generate artefacts (server side and client side) for static evidence. This can lead to a client build problem due to the ambiguous reference to attributes that appear twice in the server access bean, through different aggregations in the data model.

Example:

If a server access bean (facade definition) contains the following two startDate attributes:

• dtls$dtls$startDate
• dtls$dtls$relatedEntityAttributes$startDate

then reference to those startDate attributes inside generated client (UIM) pages need to be fully qualified to prevent an ambiguous reference error from being reported during a client build.

User Interface Impact: No

Steps to Reproduce:

1. Look at an existing custom entity that is configured for evidence generation. Choose one that has Related Entity Attributes modelled.
2. In the model, change the name of one of the attributes in the Related Entity Attribute struct to 'startDate'.
3. Now perform a 'build clean generated'.
4. Refresh Eclipse and fix up any compilation errors in the RelatedEntityAttribute implementation for the entity due to the attribute rename.
5. Now perform a 'build clean client'.
6. Issue: The client build fails for one of the pages associated with the entity due to an ambiguous reference to the 'startDate' attribute. This is due to the fact that the reference to the server access bean attribute is not fully qualified.

Resolution:

The Evidence Generator has been updated to ensure that the server access bean attributes referenced in all the generated client (UIM and VIM) pages are fully qualified.

PARTICIPANT MANAGEMENT

PO08244, WorkItem:246483 - The Type drop-down field in both the create and modify Web Address modals truncates text

Issue Description:

The create and modify Web Address modals contain a drop-down field for Type that is too narrow to display large text.

User Interface Impact: Yes

Steps to Reproduce:

1. Login as a caseworker.
2. Register a new Person.
3. From the Person home page, select Client Contacts and click on Web Addresses.
4. Click New to create a new Web Address.
5. Issue: Observe the Type drop-down field truncates large text. The same is true when editing an existing Web Address.

Resolution:

This issue was resolved by updating the drop-down field for Type to have a larger width.

Technical:

The following Web Address pages have been updated to give the type drop-down field a greater width:

• Participant_createWebAddress.uim
• Participant_modifyWebAddress.vim

Intake

PO07757, WorkItem:228320 - When Intake Resilience and Advanced Evidence Sharing are enabled, duplicate evidence records appear on an Insurance Affordability Application Case

Issue Description:

When Intake Resilience and Advanced Evidence Sharing are enabled, duplicate evidence records are shared from the Person Record to an Insurance Affordability Application Case.

User Interface Impact: No

Prerequisite(s):

The following system properties should be set:

1. curam.intake.use.resilience=YES
2. curam.aes.advancedEvidenceSharingEnabled=YES

A Logically Equivalent evidence sharing rule is configured for Person Record Identifications to Insurance Affordability Application Case SSN Details using the out-of-the-box XML configuration with Trusted Source set to Yes.

Steps to Reproduce:

1. Login as an Insurance Affordability caseworker.
2. Register a new Person and add Identification evidence with the type set to Social Security Number.
3. Create and submit a new Insurance Affordability Application.
4. Navigate to the newly created case.
5. Issue: There are two identical SSN Details evidence records on the case.

Resolution:

This issue has been resolved and duplicate evidence records are no longer shared from the Person Record to an Insurance Affordability Application Case.

Technical:

A new version of the Process Intake Application Workflow has been provided. Previously, the resiliency path through this workflow created the application case and added one or more person(s) to that case. Adding members to a case initiates the Evidence Sharing Pull Workflow before then moving on to mapping evidence from the application script to the case. This causes an issue where the SSN Details gets shared and mapped to the case simultaneously, resulting in the duplication of evidence. The new workflow delays the sharing until later so that it never runs in parallel with the mapping. This has been achieved by nesting a subflow for the Evidence Sharing Pull Workflow within the Process Intake Application Workflow.

Application Development Environment

CLIENT DEVELOPMENT ENVIRONMENT

PO07412, WorkItem:208930 - It's not possible to turn off the progress spinner by using the property that controls whether it's enabled or disabled

Issue Description:

The property curam.progress.widget.enabled, which determines whether the progress spinner is displayed or not, does not work. Even when it is set to false, the progress spinner continues to display.

User Interface Impact: No

Steps to Reproduce (In Development):

1. Update ApplicationConfiguration.properties setting curam.progress.widget.enabled=false.
2. Rebuild the client.
3. Restart the server.
4. Issue: Pages that are slow to load continue to display the progress spinner.

Resolution:

This has been resolved in the JavaScript responsible for rendering the progress spinner so that even pages that take a long time to load will not display it if it has been disabled.

PO08040, WorkItem:241162 - Collapsing and reopening a Comments field which contains a Rich Text editor loses previously entered text

Issue Description:

Collapsing and reopening a Comments field which contains a Rich Text editor sometimes results in the previously entered text being lost and the text area being no longer editable.

User Interface Impact: No

Steps to Reproduce:

1. Login as a caseworker.
2. Register a new Person.
3. Create a new Outcome Plan for this Person.
4. On the Outcome Plan, click on the Reviews tab and select the New page level action.
5. Type some text into the Comments field.
6. Collapse the Comments field by closing the toggle on the right.
7. Expand the Comments field using the toggle.
8. Issue 1: The previously entered text has been lost.
9. Issue 2: The Comments field is no longer editable.

Resolution:

The Comments field has been fixed so that closing and reopening it will not affect its contents and the field remains editable.

ACCESSIBILITY

PO07792, WorkItem:232982 - JAWS screen reader does not indicate the state of the sorted column

Issue Description:

When a column header on a sortable list is selected, the list is sorted, however the resultant sort order was not indicated in any way to a visually impaired user accessing the screen using the JAWS screen reader.
User Interface Impact: No

Steps to Reproduce:

1. Login as a caseworker.
2. Perform a person search using criteria which returns a number of people.
3. Click on a column header for the returned list of people to sort the table.
4. Issue: Screen reader does not indicate the updated state of the sorted column.

Resolution:

This has been changed so that the actual currently sorted column order is read out by screen readers such as JAWS.

PO07992, WorkItem:237627 - Color contrast violations of link text on context panels

Issue Description:

The color contrast of link text on the context panels doesn't adhere to the Web Content Accessibility Guidelines (WCAG) AA standards.

User Interface Impact: Yes

Steps to Reproduce:

1. Login as a caseworker.
2. Register a new Person.
3. Issue: The link text displaying on the light grey background of context panels fails the Web Content Accessibility Guidelines (WCAG) AA standards of text to background contrast ratio of at least 4.5 to 1 for normal text.

Resolution:

To resolve these accessibility issues, the current blue has been changed to one that gives a higher contrast ratio on a grey background, as well as a new hover colour, to maintain the overall look and feel of the user interface.

WorkItem:240095 - Color contrast violation of announcements text on the Home tab

Issue Description:

The color contrast of text on the background color (grey) in Home tab announcements doesn't adhere to the Web Content Accessibility Guidelines (WCAG) AA standards.

User Interface Impact: Yes

Steps to Reproduce:

1. Login as any user.
2. Click on the Home tab to view the announcements section.
3. Issue: The text displaying on the light grey background of announcements fails the Web Content Accessibility Guidelines (WCAG) AA standards of text to background contrast ratio of at least 4.5 to 1 for normal text.

Resolution:

To resolve these accessibility issues, the current blue has been changed to one that gives a higher contrast ratio on a grey background, as well as a new hover colour, to maintain the overall look and feel of the user interface.

PO08001, WorkItem:240102 - JAWS doesn't communicate the state of toggle button associated with a list item

Issue Description:

In a list containing expandable children with toggles, the Person Search result list, for example, the toggle state is not communicated by a screen reader. If the toggle is collapsed, a screen reader does not read that it is collapsed.

User Interface Impact: No

Steps to Reproduce:

1. Login as a caseworker.
2. Search for a Person.
3. Navigate to a toggle button for a result on the list.
4. Issue: The toggle button's state is not communicated.

Resolution:

A new attribute was added to the toggle button that allows the screen reader to communicate the state of that toggle button. When a user navigates to a toggle button on a list item, the state of the toggle button (collapsed or expanded) is now communicated by the screen reader.

Technical:

The issue was resolved by updating the TI/client/components/
client-inf/jscript/src/internal/curam/util/ExpandableLists.js file.

PO08026, WorkItem:240673 - Radio buttons in a list do not have distinguishable alternative (alt) text

Issue Description:

Previously a screen reader did not read the contextual information for the radio buttons in a list, which made it difficult for the screen reader user to associate a radio button with the list row it belonged and applied to.

User Interface Impact: Yes

Steps to Reproduce:

1. Login as a caseworker.
2. Register a new Person.
3. Navigate to the Participant Details tab, if configured for the Person, and add two employment records.
4. Create a case for the Person.
5. Click on the Evidence tab and using the New Evidence page action, add Paid Employment evidence.
6. Issue: The Select Employment Page displays the employment records, but the alt text is the same for each row making it difficult for a screen reader user to associate the radio button with the list row it applies to.

Resolution:

Now radio buttons in a list with the single-select widget convey their actual (physical) list row number to the screen reader user thus allowing them to understand the actual list context.
Technical:

A new property has been added to CDEJResources.properties to control the new accessibility reading:

• listcontrol.reading.selectors - allows for customization/localization of the screen readings associated with links in a list

This property is the text pre-pending the row number associated with the corresponding radio button.

PO08079, WorkItem:241562 - Color contrast violations of link text on the Application tabs and Evidence Dashboards

Issue Description:

The color contrast of link text on the Application tabs and Evidence Dashboards doesn't adhere to the Web Content Accessibility Guidelines (WCAG) AA standards.

User Interface Impact: Yes

Steps to Reproduce on Application Tabs:

1. Login as a caseworker.
2. Click on Person under Searches in the shortcuts panel.
3. Issue: Person Search link text displaying on the light grey background fails the Web Content Accessibility Guidelines (WCAG) AA standards of text to background contrast ratio of at least 4.5 to 1 for normal text.

Steps to Reproduce on Evidence Dashboard links:

1. Enter the search criteria for a Person and click Search.
2. Click on a Person link in the Search Results list to open the Person tab.
3. From the Person tab, click on the New Case tab menu option.
4. Select any integrated case type and click Save. The integrated case tab will open.
5. Go to the Evidence tab on the integrated case to navigate to the Evidence Dashboard.
6. Inspect the text of the Recorded links to see that it has the blue colour #4178be.
7. Issue: The Recorded link text displaying on the light grey background fails the Web Content Accessibility Guidelines (WCAG) AA standards of text to background contrast ratio of at least 4.5 to 1 for normal text.

Resolution:

To resolve these accessibility issues, the current blue has been changed to one that gives a higher contrast ratio on a grey background, as well as a new hover colour, to maintain the overall look and feel of the user interface.

PO08070, WorkItem:242058 - When using the Tab or Shift+Tab keys to navigate from the drop-down menu, the focus returns to the drop-down field instead of tabbing to the next or previous element

Issue Description:

When a drop-down menu in the Merative Social Program Management application is open and a user presses the Tab or Shift+Tab keys on a keyboard to navigate from the drop-down menu, the focus returns to the drop-down field instead of tabbing to the next or previous element.

User Interface Impact: No

Steps to Reproduce:

1. Login as a caseworker.
2. Begin navigating through the application using the Tab key.
3. When the focus is on the help menu button in the application banner, press Enter to open the menu.
4. Issue: Pressing the Tab key when the menu is opened returns the focus to the drop-down field.

Resolution:

When a user presses the Tab or Shift+Tab keys when a drop-down menu is opened, the focus moves to the next element in the tabbing order.

PO08087, WorkItem:242600 - The focus cursor does not appear when a user navigates to a Citizen Portal page where the first input field on the page is a Filtering Select field that does not have an associated help icon

Issue Description:

When navigating through the application form with the keyboard in the Citizen Portal, there are a number of pages where the first input field on the page does not automatically receive focus after navigating to the page. This occurs where the first input field is a Filtering Select widget and it does not have a help icon alongside it.

User Interface Impact: No

Steps to Reproduce:

1. Go to the Universal Access (Insurance Affordability) portal.
2. Click 'Apply for assistance with your Health Care'.
3. Create an account.
4. Navigate through the application script providing the basic details for a sole applicant.
5. Navigate to the Enter Income Details page in the Household Income section and provide the required details.
6. Using only the keyboard, click Next.
7. Issue: On the Income Deductions page, observe that the focus cursor is not visible.

Resolution:

When navigating through the application form with the keyboard in the Citizen Portal, the first input field, where that input field is a Filtering Select widget and it does not have a help icon alongside it, will receive focus automatically after navigating to the page.

Technical:

When an IEG page is loaded in the Citizen Portal and it contains Filtering Select fields, these fields are initially hidden, re-sized and then unhidden. Also in the Citizen portal, a javascript function is used to determine which field shall receive focus. When a page's first input field is a Filtering Select input field, and that field does not have a help icon alongside it, the javascript function to set the focus tries to focus on this field after it has been hidden but before it is shown again. This caused the focus cursor to not appear. Now the javascript function to set the focus is called after the input fields have been unhidden and the focus cursor is visible to users.

PO08090, WorkItem:242604 - Tables not for layout purpose are announced by the screen reader as tables for layout purpose due to wrong wording of the table summary attribute

Issue Description:

The Participant Details tab on a Person record contains a table that is used for displaying data. When a user navigates to this table using a screen reader, it is announced that this table is being used for formatting purposes only, which is incorrect.

**User Interface Impact: **No

Steps to Reproduce:

1. Login as a caseworker.
2. Navigate to the Participant Details tab on a Person record.
3. Using a screen reader, navigate to the Participant Details table using the keyboard.
4. The screen reader announces the table as being used for formatting purposes only.

Resolution:

The issue has now been fixed so that when a user navigates to the table in the Participant Details tab on a Person record using a screen reader, it no longer announces the table as being used for formatting purposes only.

Technical:

The issue was resolved by updating the HCR/webclient/components/ISProduct/Person/
Home/ISPPerson_listPersonParticipantDetails.uim file.

PO08096, WorkItem:242823 - Toggle and Menu buttons in a list do not have distinguishable alternative (alt) text

Issue Description:

The screen reader is not reading the contextual information for the toggle controls in a list as well as for the list row action menus, making it difficult for a screen reader user to associate the control with the list row it belonged and applied to.

User Interface Impact: No

Steps to Reproduce:

1. Login as a caseworker.
2. Register a new Person.
3. Click on the Evidence tab to show all the evidence recorded for the Person.
4. Issue: All the toggle arrows in the expandable list rows and the list row action menu controls have the same non-distinguishable alt text making it difficult for a screen reader user to associate the control with the list row it applies to.

Resolution:

Now the toggle arrows in the expandable list rows and the list row action menu controls convey their actual (physical) list row number to the screen reader user thus allowing them to understand the actual list context of that control.

Technical:

Following new properties have been added to CDEJResources.properties to control the new accessibility readings:

• listcontrol.reading.togglers - allows for customization/localization of the screen readings associated with the toggle controls in a list with expandable rows
• listcontrol.reading.menus - allows for customization/localization of the screen readings associated with the list row action menu controls

All the mentioned properties are the texts prepending the row number associated with the corresponding list control.

PO08103, WorkItem:242923 - The file upload button is not correctly communicated to a screen reader user as the button is read out twice when the focus is given to the element

Issue Description:

The file upload button is not correctly communicated to a screen reader user as the button is read out twice when the focus is given to the element. The user was also required to press the tab key twice to move off the button while navigating with the keyboard.

User Interface Impact: No

Steps to Reproduce:

1. Login as a caseworker.
2. Search for an existing person.
3. On the Person home page, click the Client Contact tab and select Attachments.
4. Click on the New page action.
5. Navigate focus to the file upload (Browse...) button on the New Attachment page.
6. Issue: The file upload button on the New Attachment page is not correctly communicated to a user using a screen reader. It's read out twice.

Resolution:

The issue was caused by an input element incorrectly receiving focus. Screen readers now only announce the button once and a user using keyboard navigation can navigate from the button by pressing the tab key once.

Technical:

The issue was resolved by hiding the input element of the button, which is responsible for opening the file browser from Merative Social Program Management. This was done by adding a hidden attribute to the element. This input element is now accessed using the label element. A valid key press or click on this label element will open the file browser as before.

PO08095, WorkItem:243001 - ARIA attributes are not allowed on the shortcuts panel toggle expander

Issue Description:

The toggle that expands / collapses the shortcuts panel does not have its state (expanded / collapsed) communicated by screen readers.

User Interface Impact: No

Steps to Reproduce:

1. Login as a caseworker.
2. Navigate to Cases and Outcomes.
3. Navigate, using the tab key, to the shortcuts toggle.
4. Issue: The state of the toggle button is not communicated by the screen reader.

Resolution:

This issue has been resolved and the shortcuts panel toggle's state of expanded / collapsed is now communicated correctly by screen readers.

Technical:

The issue was resolved by adding a link element to the shortcut panel's toggle button. This element contained the necessary information needed to communicate the state of the toggle via the screen readers. This link's information is changed via the toggle() function in ExpandoPane.js.

PO08105, WorkItem:243006 - When high contrast mode is enabled on the Windows OS, the announcements player buttons and the Refresh, Help and Customize buttons are not visible on the caseworker home page

Issue Description:

When high contrast mode is enabled on the Windows OS, the announcements player buttons and the Refresh, Help and Customize buttons are not visible on the caseworker home page.

User Interface Impact: Yes

Steps to Reproduce:

1. On the Windows OS, search for the High Contrast settings.
2. Enable high contrast mode.
3. Login as a caseworker.
4. Navigate to the caseworker home page.
5. Issue: Observe that the announcements player buttons and the Refresh, Help and Customize buttons are not visible when high contrast mode is enabled.

Resolution:

This was resolved by updating the underlying code to use image tags instead of background images on links. These buttons can now be viewed when high contrast mode is enabled.

PO08106, WorkItem:243069 - The person image graphic on the Person home page context panel is decorative and should not be read out by the JAWS screen reader

Issue Description:

The person image graphic on the Person home page context panel is decorative and should not be read out by the JAWS screen reader.
User Interface Impact: No

Steps to Reproduce:

1. Login as a caseworker.
2. Search for and navigate to the home page of an existing Person.
3. Start the JAWS 2018 screen reader.
4. Using the keyboard, navigate to the person image graphic in the context panel.
5. Issue: JAWS reads out "person image graphic".

Resolution:

This issue has been resolved and the person image graphic is no longer navigable to by keyboard, which means that the above message will not be read out by the JAWS screen reader.

PO08112, WorkItem:243249 - Enabling high contrast mode on the Windows OS removes the close and help buttons from modals

Issue Description:

When high contrast mode is enabled on the Windows OS, the close button icon and help button icon are not visible on modal dialogs.

User Interface Impact: Yes
Steps to Reproduce:

1. On the Windows OS, search for the High Contrast settings.
2. Enable high contrast mode.
3. Login as a caseworker and navigate to the Person search page.
4. Select the calendar icon beside the Date of Birth input field.
5. Issue: Observe that the close button and help button are not visible when high contrast mode is enabled.

Resolution:

This issue has been resolved by updating the close button and help button icons to contain an image HTML tag instead of using a background CSS image.

Technical:

This issue was resolved by updating the javascript code on the modal dialog for the relevant icons. The help and close image link icons can be updated by updating the image source file path in the CDEJResources.properties file.

• modal.close.button.icon
• modal.close.button.icon.hover
• modal.help.button.icon
• modal.help.button.icon.hover

PO08116, WorkItem:243284 - When a user navigates through the application using the Tab key, there exists a hidden element before the main content area that is receiving focus

Issue Description:

When a user navigates through the application using the Tab key, there exists a hidden element before the main content area that is receiving focus.
User Interface Impact: No

Steps to Reproduce:

1. Login as a caseworker.
2. Begin navigating through the application using the Tab key.
3. Issue: Before the user can get to the main content area, a hidden element receives focus.

Resolution:

A user using the Tab key to navigate through the application will no longer focus on the hidden element before arriving in the main content area. The hidden element was given a tab index of -1.

PO08115, WorkItem:243289 - The link associated with the Citizen Context Viewer does not have a user-friendly label, which means users of assistive technology will not be able to determine the link's destination or purpose

Issue Description:

The link associated with the Citizen Context Viewer does not have a readable, user-friendly label. Screen readers such as JAWS read out the actual link URL, 'flex/Citizen_resolverCitizenViewer', for example, instead of a more user-friendly text.
User Interface Impact: No

Steps to Reproduce:

1. Login as a caseworker.
2. Click on the Cases and Outcomes tab.
3. Click on Person under Searches in the shortcuts panel.
4. Enter search criteria and click Search.
5. Click on one of the results returned to open the Person tab.
6. Click on the Citizen Context Viewer link on the top right of the person's profile picture (icon is an arrow pointing to the top-right).
7. Issue: The URL 'flex/Citizen_resolverCitizenViewer' is read by screen readers. This is inconsistent with other links as those links have associated text that is more user-friendly.

Resolution:

The issue has now been resolved by adding a label and title attribute to allow the communication of a user-friendly label. Navigating to the Citizen Context Viewer button and viewing Link Lists will now result in screen readers reading this new label.

PO08118, WorkItem:243292 - The JAWS screen reader is reading out hidden content related to the Login button

Issue Description:

On the Login page, the JAWS 2018 screen reader reads out two login elements on the page. One of these is a hidden element and should not be read out.
User Interface Impact: No

Steps to Reproduce:

1. Turn on the JAWS 2018 screen reader.
2. Navigate to the Login page.
3. Using the down arrow key, navigate from the Password field to the Login button.
4. Issue: JAWS reads out the 'Login button' and then on another down arrow key press it reads out 'Link login'.

Resolution:

This issue has been resolved by adding an aria-hidden attribute to the hidden element on the Login page. The element is no longer read out by the JAWS 2018 screen reader.

PO08193, WorkItem:245004 - In the Universal Access application, there are two 'Skip to Main Content' links which contain the same link text but have different behaviors

Issue Description:

In the Universal Access application, there are two 'Skip to Main Content' links that contain the same link text but have different behaviors.

User Interface Impact: No

Steps to Reproduce:

1. Navigate to the Univeral Access home page.
2. Click Apply For Benefits.
3. Choose Start your application without creating an account or logging in to the system and click Next.
4. Choose Human Services Application Form and click Next.
5. Choose Medical Assistance and click Next.
6. Press Shift+Tab until focus is on the Print element on the form page.
7. Press Shift+Tab again. The focus is given to a hidden element. Screen readers read out 'Skip to main content'.
8. Press Shift+Tab until focus is on the 'Skip to Main Content' link in the top left of the page.
9. Issue: There are two 'Skip to main content' links that behave differently to each other. This can be confusing to users.

Resolution:

This issue has been resolved and the text of the second link has been changed to 'Skip to Form Content'. This link now links to a 'Form Content Main Region'. The element cannot be given focus by tabbing, but can still be accessed via arrow keys to ensure accessibility to users utilizing screen readers.

Technical:

The issue was resolved by changing the property text to better reflect the behavior of the second link. The link was also given a tab index of -1 to avoid users who do not utilize screen readers tabbing to the hidden element. These changes were made in various files within the BizInf stream. These files are IEGPlayerRenderer.java, ieg-config.properties, DomainPlugInsConfig.xml, and IEGPropertyName.java.

LOOK & FEEL

PO08104, WorkItem:242937 - Radio buttons and checkboxes are not reasonably visible enough to the user

Issue Description:

When printing a page that contains a selected radio button or a checked checkbox, the same radio button or checkbox appears unselected/unchecked on a printed version of the page. Therefore, users could be missing information when only reviewing a printed version of the page. This issue can only be seen when your browser setting for printing background graphics is disabled.

User Interface Impact: No

Steps to Reproduce:

1. Login as a caseworker.
2. Navigate to the Case Search page.
3. Check the checkbox labelled Investigations.
4. Ensuring your browser setting for printing background graphics is disabled, print this Case Search page using the page level print icon.
5. Issue: The checkbox labelled Investigations appears unchecked on the printed version of the page.

Resolution:

Print specific styling was added to checkboxes and radio buttons so that selected radio buttons and checked checkboxes appear on printed versions of pages containing those controls.

WorkItem:247316 - Selected color updates to ensure full compliance with the WCAG AA standards

Issue Description:

Selected Merative Social Program Management user interface colors have been updated to ensure full compliance to the Web Content Accessibility Guidelines (WCAG) AA standards of text to background contrast ratio of at least 4.5 to 1 for normal text. WCAG standards help make web content more accessible to people with disabilities.

The definition of the selected user interface colors are as follows:

• #4178BE – “Blue50”: Primary use: Live or clickable item (for example, link text, actionable and clickable icons)
• #325C80 – “Blue60”: Primary use: Hover state item (for example, hover state for link text, hover state for actionable and clickable icons)
• #464646 – “Grey70”: Primary use: Default body text (for example, list text, cluster text, context panel text)

User Interface Impact: Yes

Resolution:

The following color updates were made:

• #4178BE – “Blue50” excluding clickable icons updated to new IBM Design color #1F57A4 – “Blue60”
• #325C80 – “Blue60” updated to new IBM Design color #25467A – “Blue70”
• #464646 – “Grey70” updated to #000000 – “Black”

WIDGETS

PO08232, WorkItem:246138 - Use of the '#' character in Microsoft Word template data details causes the resultant Microsoft Word document to display incorrectly

Issue Description:

Microsoft Word communications in the Social Program Management application are based on a template that is created and maintained in Microsoft Word. All Microsoft Word templates are associated with either participants or with cases.

When communication of type Microsoft Word is created in the application and the data used as input into the template fields contains a '#' character, the resultant Microsoft Word document generated fails to display correctly. All of the data in the fields up to where the '#' character is included displays correctly, but the other template fields display the error message 'Error - no data retrieved' instead of the field values, and the data specified after the '#' character is not included in the resultant generated Microsoft Word document.

User Interface Impact: No

Steps to Reproduce:

1. Login as a caseworker.
2. Click on Register Person and Create Case under Cases in the shortcuts panel.
3. Enter the Person details and select any case from the Type drop-down.
4. On the newly created case, click on the Contact tab and select Communications.
5. Select New Microsoft Word from the page action menu.
6. On the New Microsoft Word Communication dialog, choose the Case Participant and click Next.
7. Enter a Subject and manually type in an address. Use a '#' character in one of the address fields, 'Room #10' for Street 1, for example.
8. Complete the address and select an available Microsoft Word Template that will use the field containing the '#'.
9. Click Save. This will open the Microsoft Word and attempt to populate the template.
10. Issue: The Microsoft Word document will open. The Microsoft Word template fields after the '#' character will display the error message 'Error - no data retrieved' in place of the remaining address field values.

Resolution:

The presence of a '#' character in data used to populate Microsoft Word communication template details no longer causes an issue and any data containing that character will be populated correctly into the required template fields in the resultant generated Microsoft Word document.

Technical:

The algorithm used to process and populate Microsoft Word template data has been updated to handle the presence of '#' characters correctly. This character did have a special meaning within that algorithm but now the combination of the following characters, '#|#', is used to delineate the template data for the different fields.

Business Services

PO07201, WorkItem:198146 - A user can subscribe to a work queue without selecting a work queue, no validations occur

Issue Description:

From the Inbox, on selecting to subscribe to a work queue where the caseworker does not select any work queue, they can complete the process without receiving any notification or error message.

**User Interface Impact: **Yes

Steps to Reproduce:

1. Login as a caseworker.
2. Click on the Inbox tab.
3. Select 'Subscribe to a Work Queue' under Work Queues in the shortcuts panel.
4. Enter a Work Queue Name and click Search.
5. Do not select any work queues from the Search Results and click Save.
6. Issue: No validation is thrown when the user saves the work queue subscription without selecting at least one work queue, and no work queue subscriptions are created.

Resolution:

The following validation message has been added, which is presented if a caseworker does not select any work queue during the subscription process: 'Work Queue(s) must be selected'.

CORRESPONDENCE MANAGEMENT

PO08270, WorkItem:246819 - Cannot reactivate a closed product delivery case

Issue Description:

It's not possible to reactivate a product delivery case if there is no Case Reactivation Client Communication template available, even if printing is turned off for case communications.

User Interface Impact: No

Prerequisite(s):

Turn off case communications:

1. Login as a system administrator.
2. Click on the System Configurations tab.
3. Click on Property Administration under Application Data in the shortcuts panel.
4. Search for a property with the name 'curam.case.printcasecommunications'.
5. Use the Edit Value row level action to modify the value of the property to NO and click Publish.

Ensure no Case Reactivation Client Communication template(s) exists:

1. There are 3 Case Reactivation Client Communication templates shipped with the product as demo data, one for en, en_US and en_GB.
2. These templates will not exist on a deployed system unless the customer took one or more of them and made them their own, or created their own custom template(s).
3. If Case Reactivation Client Communication templates do exist, they can be removed as follows:
   • Login as a system administrator.
   • Click on the System Configurations tab.
   • Click on XSL Templates under Communications in the shortcuts panel.
   • Use the Check Out Template action to check out the Case Reactivation Client Communication templates and modify their Template ID to be that of an unused Template ID Code.
   • Click Save.
   • Use the Check In Template action to check in the individual modified templates.
4. Alternatively, remove the Case Reactivation Client Communication templates from the database (XSL Template entity).

Steps to Reproduce:

1. Login as a caseworker.
2. Register a new Person.
3. Create a product delivery for this Person.
4. Add the necessary evidence and apply changes.
5. Submit, approve and activate the product delivery.
6. Close the product delivery.
7. Reactivate the product delivery.
8. Issue: The following exception is thrown: A suitable pro forma template could not be found while sending 'Case Reactivation Client Communication'.

Resolution:

The logic for reactivating a product delivery has been updated to only look up the template for printing the communication if the environment variable for governing the printing of case communications, 'curam.case.printcasecommunications', is set to YES.

Common Intake

PO08233, WorkItem:246159 - The date field is blank on the My Applications list page

Issue Description:

The date field is blank on the My Applications list page.
User Interface Impact: No

Steps to Reproduce:

Prerequisite(s):

1. Update the relevant section shortcuts panel (.ssp) file and associated properties for the caseworker workspace to add the My Applications link node.
2. Run the database target 'build inserttabconfiguration' so that the My Applications link appears in the shortcuts panel.

Scenario:

1. Login as a caseworker.
2. Register a new Person.
3. Click on the Care and Protection tab and select Applications.
4. Select New Application Case from the page action menu.
5. Ensure all the mandatory details are specified and click Save.
6. From the shortcuts panel, click on My Applications.
7. Issue: The date is blank on the My Applications list page.

Resolution:

This issue has been resolved and the application date is now mapped back on the My Applications list page.

Cúram Modules

Outcome Management

PO07726, WorkItem:227059 - Unable to view the timeline chart of a factor when the assessment only produces a single factor result

Issue Description:

When an assessment is configured to determine and display results by score and the assessment is reassessed one or more times, the user is able to view a timeline of the change in score for each individual factor that was assessed. When the assessment produces a single factor result, it is not possible to view the timeline chart for the single factor.

User Interface Impact: No

Steps to Reproduce:

1. Configure an assessment that determines classifications by score and allows for a single classification determination for a factor to be made.
2. Login as a caseworker.
3. Register a new Person.
4. Create an Outcome Plan for the Person.
5. Click on the Assessments & Factors tab.
6. Click on New.
7. Select the assessment to run.
8. Answer the questionnaire where you’ll only get a single classification determination for a factor.
9. Review the results graph.
10. Issue: There is only an Overview button displayed. There is no factor button to drill down into the factor where the user should be able to view the timeline chart.

Resolution:

The specific check on the factor size has been removed to display the timeline chart even for single factor results.

PO07999, WorkItem:240056 - Smart Navigator search is returning the default Outcome Plan home page rather than the one that was configured through the administration application

Issue Description:

Smart Navigator Outcome Plan search does not open the custom home page configured against the Outcome Plan in the administration application, but instead opens the default version of the page (OutcomePlan_home).

User Interface Impact: No

Steps to Reproduce:

1. Login as an administrator.
2. Configure an Outcome Plan with a different home page.
3. Login as an Income Support caseworker.
4. Register a Person and create an Income Support case.
5. Login as a Child Welfare caseworker.
6. Create an Ongoing Case for the registered Person.
7. Click on the Outcome Plans tab and use the New page action to create an Outcome Plan configured at step 2.
8. Login as an Income Support caseworker.
9. Use Smart Navigator to search for the Person registered including the keyword 'op'.
10. Select the Outcome Plan returned in the search results.
11. Issue: The default home page is displayed instead of the configured one.

Resolution:

This has been resolved by updating the Smart Navigator Person Outcome Plan Search to retrieve the home page configured against the Outcome Plan being opened.

PO08094, WorkItem:242811 - The Participation tab on an Outcome Plan Action throws an application error

Issue Description:

When creating an action within an Outcome Plan, if the action is configured to require client participation, a frequency and duration for the participation are specified and daily participation is then recorded. It is not possible to record participation using the Participation tab within an action because the tab displays an 'An Application Error Has Occurred' message.

User Interface Impact: No
Steps to Reproduce:

1. Login as a caseworker.
2. Register a new Person.
3. Click on New Outcome Plan under Outcome Plans in the shortcuts panel.
4. Search for the registered Person and select the person.
5. Give the Outcome Plan a Type and a Name.
6. Click Finish.
7. Click on the Activities tab.
8. Select New Action from the action menu.
9. On the first page of the wizard select or define a new action that is configured to require client participation.
10. Navigate through the pages of the wizard and input all mandatory details, including frequency and duration.
11. Click Finish.
12. On the Activities tab click on the new activity link, for example, Become Self Employed.
13. The Activity tab opens. Click on the Participation tab.
14. Issue: The page displays the message: 'An Application Error Has Occurred'.

Resolution:

This issue has been resolved by updating the Participation tab to display the participation calendar for an Outcome Plan Action.

PO08214, WorkItem:245424 - In the Outcome Plan Workspace, dragging and dropping an Activity onto an Objective intermittently results in the Activity incorrectly being shown twice

Issue Description:

In the Outcome Plan Workspace, dragging and dropping an Activity onto an Objective intermittently results in the Activity incorrectly being shown twice.
User Interface Impact: No

Prerequisite(s):

1. Login as an administrator and navigate to Outcome Plans under Outcome Management in the shortcuts panel.
2. Click on the Self Sufficiency Outcome Plan.
3. Click on the Cases tab and select Add Cases to add an integrated case.
4. Click on the Recommendations tab and add any type of Recommendation from the page action menu.
5. Click on the Objectives tab and select Add Objective to add an Objective.

Steps to Reproduce:

1. Login as a caseworker.
2. Register a new Person.
3. Create an integrated case for the Person of the same type defined above.
4. Add a Self Sufficiency Outcome Plan to the integrated case.
5. In the Outcome Plan, click on the Workspace tab.
6. Create a new Objective by using the drag and drop functionality.
7. Make sure the toggle is collapsed.
8. Create a new Activity within the Objective by using the drag and drop functionality.
9. Enter the required information and click Save.
10. Issue: Within a second or two after clicking on the toggle, there will be two activities visible although the user created only one.

Resolution:

Both the creation and clicking on the toggle read the newly added Objective resulting in two activities displaying. To avoid concurrent calls the new item will be read only when the toggle is expanded, and this happens automatically.

Social Enterprise Collaboration

PO08176, WorkItem:244820 - In the Citizen Context Viewer (CCV), relationships with Prospect Persons are displayed as Not Shown

Issue Description:

In the Citizen Context Viewer (CCV), relationships with Prospect Persons are displayed as Not Shown.

User Interface Impact: No

Steps to Reproduce:

1. Login as a system administrator.
2. Select Properties under Application Data in the shortcuts panel.
3. Search for the property 'curam.evidence.pdc.personenabled', set its value to NO and publish.
4. Login as a caseworker.
5. Register a new Prospect Person.
6. Register a new Person.
7. From the Person home page, click on the Background tab.
8. Add any type of relationship to the Prospect Person registered above.
9. Select the Citizen Context Viewer arrow near the photo icon for the registered Person.
10. Select Family.
11. Issue: Observe that '1 Not Shown' displays.

Resolution:

A new system property 'curam.ise.ccv.display.prospects' has been introduced to control the display of Prospect Persons in the Citizen Context Viewer. This has been set to NO by default, but it can be turned on to facilitate the display of Prospect Persons in the Citizen Context Viewer.

Provider Management

PO07760, WorkItem:244220 - A product delivery case associated with a service delivery cannot be hidden on the integrated case home page

Issue Description:

Product delivery cases are created and associated to three of the four types of service deliveries in order to support eligibility and financials processing. By default, these product delivery cases should not be displayed on the home page of the integrated case within which the service delivery is created. The product delivery cases should not be displayed because caseworkers are not intended to interact with the cases but instead view and manage eligibility and financials information on pages within the service delivery itself.

User Interface Impact: No

Steps to Reproduce:

1. Login as an administrator.
2. Click on the Administration Workspace tab.
3. Click on Services under Provider Management in the shortcuts panel.
4. Choose a service, Child Care, for example, click on the Delivery tab and select Edit.
5. For Delivery Type choose Service Delivery with Eligibility.
6. For Product, search for an existing Product on the system and click Save.
7. Login as a caseworker.
8. Search for an existing integrated case on the system, one associated with the product selected above.
9. Click on the Services tab and select the New page action.
10. Choose the service selected above, Child Care, for example.
11. Navigate to the integrated case home page and notice the product delivery case is displayed under cases.
12. Issue: A product delivery case should not be displayed since it is associated with a Service Delivery with Eligibility.

Resolution:

To facilitate a product delivery associated with service delivery not being displayed on the (default) integrated case home page, a new public interface, ProductFilter, has been introduced. This is called from the facade IntegratedCase.listProduct(). Out-of-the-box, there is an implementation of the API ProductFilter.filter() in Provider Management which returns true if the underlying product is associated with one of the following service delivery types:

• Product Delivery
• Service Delivery with Eligibility
• Product Delivery with Invoicing

The API returns false for everything else, which means that all other product deliveries will be displayed by default.

PO08208, WorkItem:245281 - The Description label wraps on the New Attachment and Edit Attachment modals for Incidents

Issue Description:

On the New Attachment and Edit Attachment modals for Incidents, the Description label wraps as the pages are not wide enough.

User Interface Impact: Yes

Steps to Reproduce:

1. Login as a Provider Management resource manager.
2. Search for an existing Provider on the system.
3. Click on the Incidents tab and click the New page action.
4. Enter the mandatory details and click Save.
5. Click on the incident link to open the Incident tab.
6. Click on the Attachments tab and click the New page action.
7. Issue 1: The Description label wraps on the New Attachment page.
8. Enter the attachment details and click Save.
9. Use the Edit row level action to modify the attachment.
10. Issue 2: The Description label wraps on the Edit Attachment page.

Resolution:

This issue has been resolved by increasing the width of the pages for capturing and modifying Incident attachments.
Technical:

The issue has been resolved by increasing the width of the following UIM pages:

• ProviderManagement_createIncidentAttachment.uim
• ProviderManagement_modifyIncidentAttachment.uim

PO08229, WorkItem:246017 - Truncated date field in the New Service modal when associating a service offering to a provider

Issue Description:

When associating a service offering to a provider, the date entered in the Start Date field on the New Service modal is only partially visible when using the minimum supported resolution of 1366x768.

User Interface Impact: No

Steps to Reproduce:

1. Login as a Provider Management resource manager.
2. Click on the Providers and Services tab.
3. Click on My Providers under Providers in the shortcuts panel.
4. Open the home page of any provider.
5. Select New Service from the tab level actions menu.
6. Enter 02/28/2018 into the Start Date field.
7. Issue: The date entered is only partially visible.

Resolution:

The Start Date field width has been increased so that it is now fully visible once a date has been entered.

Technical:

The width of the Start Date field has been increased on the following UIM page so that the date is fully visible:

• ProviderManagement_addServiceOfferingForProvider.uim

Supervisor Workspace

PO07180, WorkItem:197257 - The time element of the start and end fields are not visible in the Task Redirection page

Issue Description:

In order to capture Task Redirection, the user must enter Start and End dates. The time element of the Start and End fields of the page Task Redirection are not visible.

User Interface Impact: Yes

Steps to Reproduce:

1. Login as a supervisor.
2. Click on the Team and Workloads tab.
3. Click on My Users under Users in the shortcuts panel.
4. Select any user from the list.
5. Select Task Redirection from the user workspace tab menu.
6. Issue: The time element of the start and end fields are not visible in the Task Redirection page.

Resolution:

This issue has been resolved by updating the styling on the Task Redirection UIM pages. The solution involved changing the Supervisor_redirectTasksToUsers.uim by moving the cluster, which contains the date and time fields, outside the parent cluster.
Technical:

The styling has been updated on the following UIM pages so that the date and time fields rendered correctly:

• Supervisor_redirectTasksToUsers.uim
• User_createTaskRedirection.uim

PO07188, WorkItem:197857 - In Supervisor Workspace, forwarding multiple tasks fails when an active task redirection exists for the user they are being forwarded to

Issue Description:

In Supervisor Workspace, forwarding multiple tasks fails when an active task redirection exists for the user they are being forwarded to.

User Interface Impact: No

Steps to Reproduce:

1. Login as a supervisor.
2. Click on the Team and Workloads tab.
3. Click on My Users under Users in the shortcuts panel.
4. Click on one of the users, CASE WORKER, for example, to open the user workspace.
5. Click on the Tasks tab of the user workspace.
6. From the user workspace tab menu select Task Redirection.
7. Select a Redirect To User, FINANCIAL USER, for example, specify a start date / time in the future and click Save.
8. Click on the Task tab and select Redirection History. Ensure that the redirection is active.
9. Click on My Users under Users in the shortcuts panel and select any user in the list who has more than one task assigned to them.
10. Click on the user's Tasks tab.
11. From the Assigned Tasks page menu, choose Forward.
12. On the Forward Tasks modal, select the user (from step 4) under My Users who has the active Task Redirection.
13. Enter some search criteria and click Search.
14. Select more than one task and click Save.
15. Issue: The task forwarding fails with the exception 'The task(s) cannot be forwarded because the user is currently being blocked from the allocation of new tasks.' regardless of the fact that task allocation is not blocked.

Resolution:

The forwarding of multiple tasks to another user only checked if there was an active task redirection for the user they were being forwarded to. It didn't check if this task redirection represented an allocation blocking for that user. The functionality has been updated to check if a task redirection represents an allocation blocking and throws the above exception only in that instance.

PO07194, WorkItem:198030 - Reassigning a case from the case workspace results in the case opening in a new tab

Issue Description:

From the Case Workspace, after reassigning a case using the Reassign Case action, the current case workspace tab is not refreshed and updated with the new case owner details. Instead, a new case workspace tab is opened displaying the updated case owner details.

User Interface Impact: Yes

Steps to Reproduce:

1. Login as a supervisor.
2. Click on the Team and Workloads tab.
3. Click on User Workload under Users in the shortcuts panel.
4. Enter details in the filter criteria section of the page in order to retrieve cases and click Search.
5. Click on any case listed on the page.
6. Select Reassign Case from the tab menu.
7. Search for a new owner in the Reassign Case modal.
8. Click Save.
9. Issue: A new workspace case tab is opened displaying the updated case owner details.

Resolution:

When a supervisor reassigns a case, the current workspace case tab is refreshed with the updated case owner details. A new tab is no longer opened for the same case workspace.

PO07210, WorkItem:198466 - Task assignment on a task does not display a list of tasks assignees for a reserved task

Issue Description:

Reserving tasks from the Work Queue Workspace or Case Workspace to a user using the Reserve For action does not result in the Task Assignments page in the Task tab being updated with the new assignee. This issue only arises where there are existing tasks assigned to the user. If the user does not have existing tasks assigned, or if tasks are reserved from the User Workspace, the Task Assignments page is updated correctly.

User Interface Impact: No

Prerequisite(s):

1. The user 'CASE WORKER' must already have one task assigned to them.

Note: This step is required in order that the user will have other tasks assigned prior to the supervisor reserving a task for them.

Steps to Reproduce:

1. Login as a supervisor.
2. Click on the Inbox tab.
3. Select New Task from the page menu.
4. Enter the Subject field and select 'Work Queue' in the drop-down menu of the Assign To field, and search for ' SUPERVISORWORKQUEUE'.
5. Click Save.
6. Click on the Team and Workloads tab.
7. Expand the Shortcuts menu, Users, and click on My Work Queues.
8. Click on Org Unit Subscribed tab.
9. Click on hyperlink 'SUPERVISORWORKQUEUE' and then select the Assigned Tasks tab to display the task previously created.
10. Click on the row level action menu for the task and select Reserve For.
11. Select 'CASE WORKER' in the drop-down and then click Save.
12. Search for the Task that has been assigned to the user 'CASE WORKER'.
13. Open the task home page by clicking on the task identifier and then click on the Assignments tab.
14. Issue: Only the assignment to the 'SUPERVISORWORKQUEUE' is shown. The assignment to 'CASE WORKER' is missing. The same issue occurs when tasks are reserved from one user to another, for example, reserving from the supervisor user to the case worker user.

Resolution:

This display issue is now resolved by updating a SQL query when the Reserve For menu action is called, at the time when the new task assignment entry needs to be created for the task. The SQL query has been updated by adding a new statement to the WHERE close to filter the results by adding the current task id. The Assignment tab now displays a list of task assignees for a reserved task.

PO07280, WorkItem:208937 - Tasks queued for forwarding via batch that cannot be processed due to an active allocation blocking are not retrievable in Forward Reserved Tasks process

Issue Description:

In Supervisor Workspace, tasks assigned in bulk may need the Task Forward Batch process to run to complete the forwarding if the number being assigned is above the threshold governed by the 'curam.batch.bulktaskforward.deferredprocess.max.processing.count' property.

When the Task Forward Batch process does run, tasks being forwarded to a user who has an active allocation blocking will not be processed. These records are then not searchable as part of the Forward Reserved Tasks process. This prohibits the tasks from being forwarded to a user who does not have an active allocation blocking set up against them.

User Interface Impact: No

Steps to Reproduce:

Prerequisite(s):

This step ensures that bulk reassignment using the batch process can be tested with only two tasks instead of the default value of 100.

1. Login as a system administrator.
2. Click on the System Configurations tab.
3. Select Property Administration under Application Data in the shortcuts panel.
4. Type 'curam.batch.bulktaskforward.deferredprocess.max.processing.count' into the Name field and click Search.
5. Modify the value of the record returned from 100 to 1 and click the Publish page action.

Setting up the tasks to be forwarded

1. Login as a supervisor.
2. Click on the Inbox tab.
3. Select New Task under Tasks in the shortcuts panel.
4. Enter text in the Subject field and tick the Add To My Tasks checkbox.
5. Repeat this two times.

Forwarding the tasks

1. Click the Team and Workloads tab.
2. Select My Users under Users in the shortcuts panel.
3. Click the supervisor user hyperlink to open the supervisor User Workspace.
4. Click on the Task tab and then select Open Tasks.
5. Select the Forward Reserved Tasks page action.
6. On the Forward Tasks page, select case worker in the My Users drop-down.
7. Tick the 'List all tasks reserved by the user' checkbox and click Search.
8. The Open Tasks assigned to the supervisor user will be returned.
9. Use the multi-select checkbox to select all tasks and click Save.
10. The following informational is displayed: 'There are too many tasks selected to forward now. This forward will need to be performed in batch mode, please schedule with your administrator'.

Set up the allocation blocking on the forwarded to user

1. Select My Users under Users in the shortcuts panel.
2. Click on the case worker hyperlink to open the case worker User Workspace.
3. Select Allocation Blocking from the Workspace menu.
4. Enter a start date and time in the future and click Save.

Run the Task Forward Batch process

1. Roll the server date forward to a time when the allocation blocking is active.
2. Login as a system administrator.
3. Click on the System Configurations tab.
4. Click on Processes under Batch in the shortcuts panel.
5. Type 'Task Forward Batch' in the Name / Description field and click Search.
6. Select the Execute row level action for the Task Forward Batch.
7. Leave the parameters blank in the modal and click Execute to queue the batch process.
8. Run the batch process.
9. Note: The queued tasks will not be processed because of the active allocation blocking on the forwarded to user.

Search for the unprocessed tasks

1. Login as a supervisor.
2. Click the Team and Workloads tab.
3. Select My Users under Users in the shortcuts panel.
4. Click the supervisor user hyperlink to open the supervisor User Workspace.
5. Click on the Task tab and then select Open Tasks.
6. Select the Forward Reserved Tasks page action.
7. On the Forward Tasks page, select case worker in the My Users drop-down.
8. Tick the 'List all tasks reserved by the user' checkbox and click Search.
9. Issue: The Open Tasks assigned to the Supervisor User are not returned.

Resolution:

When the Task Forward Batch process runs, an exception is thrown for any task which cannot be processed due to an active allocation blocking on the forwarded to user. An attempt is then made to update the status of the queued task, on the GenericBatchProcessInput entity, to 'Failed', within the exception block. However, this entity update will never be persisted as the transaction is rolled back when the exception is thrown. Instead, the update of the status of the skipped records to 'Failed' needs to happen within the processSkippedRecord batch API associated with the Task Forward Batch process.

The update of the status of the skipped records to 'Failed' has been moved to the processSkippedRecord API. Now when the Task Forward Batch process runs, any records that cannot be processed due to an allocation blocking have their status successfully set to 'Failed'. Once this happens, the tasks are searchable as part of the Forward Reserved Tasks process.

PO08008, WorkItem:240305 - The Cancel button on the Task Details manage pages does not close those pages

Issue Description:

When a specific task is opened and task actions selected from the Task Details page, the user is not able to close the following task pages: Forward, Reserve, Defer, Reallocate, Unreserve, Restart, Close and Add Comment using the Cancel button. The pages remain open and the only way to close them is by using the cancel icon on the top right-hand corner of the page.
User Interface Impact: No

Steps to Reproduce:

1. Login as a supervisor.
2. Click on the Team and Workloads tab.
3. Click on My Users under Users in the shortcuts panel.
4. Click on one of the users in the list to open the user workspace.
5. Click the Tasks tab in the workspace and select Open Tasks.
6. Click on the Forward Reserved Tasks page action.
7. Check 'List all tasks reserved by the user' and click Search.
8. Open any task from the list returned.
9. The Task Details screen opens.
10. In the Manage section of the page, click Forward.
11. When the Forward Task modal opens, click on the Cancel button.
12. Issue: The Cancel button does not work and the page remains open.

Resolution:

This issue has been resolved and now clicking on the Cancel button on the Task Details manage pages closes those respective pages.

Universal Access

PO08258, WorkItem:246592 - The batch process 'CitizenWorkspacePurgeNonReferencedMotivationsProcess' is not documented

Issue Description:

The batch process 'CitizenWorkspacePurgeNonReferencedMotivationsProcess' can be used to remove motivations data that is inaccessible by the user. Data can become inaccessible if, for example, a browser window is closed abruptly and an in progress application or modal is deleted without being submitted. This batch process is not documented.

User Interface Impact: No

Resolution:

The Merative Social Program Management batch process reference guide has been updated to include details about 'CitizenWorkspacePurgeNonReferencedMotivationsProcess' such as the type of data that is removed and the method used. For more information, see https://curam-spm-devops.github.io/wh-support-docs/spm/pdf-documentation

Intelligent Evidence Gathering

WorkItem:248912 - Universal Access Responsive Web Application: Cluster containers missing white space

Issue Description:

When a cluster contains questions that are grouped in a container without a divider to separate them, the values display as one single value. This only affects users of the Universal Access Responsive Web Application.

User Interface Impact: No

Steps to Reproduce:

1. Navigate to an IEG page with a container element that wraps question elements in a cluster.
2. Navigate to the summary page that contains the cluster and container.
3. Observe that the values in the container are not separated by a white space.

Resolution:

When a container is in a cluster, a white space is now inserted between values where no explicit divider is specified.

PO08264, WorkItem:248953 - Universal Access Responsive Web Application: Remove unwanted calls to getCurrentPage from IEGEngineAPI

Issue Description:

The IEG APIs that handle calls from Universal Access Responsive Web Application are retrieving the details for the current page in multiple places, resulting in different potential issues when the page is loaded.
For example:

• IEG Expressions are not evaluated when the user clicks the back button
• IEG Default Value Expressions are not evaluated when they are in a loop statement
• IEG List Questions values are lost when resuming an IEG script.

**User Interface Impact: **No

Resolution:

The sequence of events that are called when a page is submitted (answers submitted, decision on the next logical page, page details retrieved) no longer retrieves the current page details multiple times.

PO08252, WorkItem:248954 - Universal Access Responsive Web Application: Disabled codetable hierarchy descriptions are not displayed on the summary page

Issue Description:

Disabled codetable hierarchy descriptions are not displayed on the summary page. The corresponding codes are displayed instead.

User Interface Impact: Yes

Steps to Reproduce:

1. Update an IEG script to set a question value to a disabled codetable code using ‘set-attribute’ element and display that value on the summary page.
2. In the Universal Access Responsive Web Application, apply for a benefit using that IEG script.
3. Observe that the codetable code value is displayed on the summary page for the script in the application.

Resolution:

Disabled codetable hierarchy descriptions are now displayed on the summary page.

WorkItem:248955 - Universal Access Responsive Web Application: List containers missing white space

Issue Description:

When list elements contain columns grouped in a container, and no divider separates them, they appear as one single value.

User Interface Impact: No

Steps to Reproduce:

1. Select an IEG script that has a container element that wraps existing column elements in a list.
2. In the Universal Access Responsive Web Application, apply for a benefit using that IEG script.
3. Navigate to the summary page where the list is present.
4. Observe that values within a container are not separated by a white space.

Resolution:

When a container is in a list, a white space is now inserted between values where no explicit divider is specified.

PO08268, WorkItem:248956 - Universal Access Responsive Web Application: List questions on a summary page don't have values

Issue Description:

List questions on summary pages are not showing values that had been selected on previous pages.

User Interface Impact: Yes

Steps to Reproduce:

1. Select an IEG script that has both single and multi-select list-question elements, both on a regular page and a summary page.
2. In the Universal Access Responsive Web Application, apply for a benefit using that IEG script.
3. Navigate to the summary page by selecting values for the list-questions.
4. Observe that the values are not displayed on the summary page.

Resolution:

List-question values, whether they are single-select or not, are now correctly displayed on summary pages.

PO08301, WorkItem:248957 - Universal Access Responsive Web Application: Performance issue when submitting answers

Issue Description:

There was a performance issue when submitting answers in an IEG script where the IEGSCRIPTINFO table contained multiple very large scripts, resulting in a noticeable amount of time to complete submitting the answers.

User Interface Impact: No

Steps to Reproduce:

1. Open the citizen application in an environment where the IEGSCRIPTINFO table contained multiple very large scripts.
2. Select and run an IEG script.
3. Issue: The answers take a noticeable amount of time to submit.

Resolution:

This full table read was removed as it was used to perform a validation that can be done elsewhere, so the performance degradation can no longer be seen.

WorkItem:248958 - Universal Access Responsive Web Application: Mandatory field validations are not displayed where IEG script pages contain a currency input field

Issue Description:

Mandatory field validations are not displayed where IEG script pages also contain a currency input field.

**User Interface Impact: **Yes

Steps to Reproduce:

1. Select an IEG script that has mandatory field(s) and a currency type field(s) on the same page.
2. In the Universal Access Responsive Web Application, apply for a benefit using that IEG script.
3. Navigate to the script page containing the mandatory question(s) and currency type question.
4. Click the Next button without providing mandatory question values.
5. Observe that no validation messages are shown on the screen.

Resolution:

Mandatory fields validations are now displayed when currency type input fields exist on the same IEG script page.

Evidence Broker

PO07981, WorkItem:239714 - Selecting the ’Set as Latest of Incoming' action, ‘Correction’ option does not correctly validate the effective date as latest on the timeline

Issue Description:

When choosing Correction as the 'Set as Latest of Incoming' action from the existing evidence actions menu, no validations are thrown when the specified Effective Date overlaps with the Incoming Evidence timeline. This means that it's possible to set the existing evidence as something other than the latest in the timeline.

User Interface Impact: No

Steps to Reproduce:

1. Login as an administrator.
2. From Evidence Sharing under Rules and Evidence in the shortcuts panel, configure evidence sharing between an application case and its associated integrated case, with Trusted Source set to Yes.
3. Login as a caseworker.
4. Register a new Person.
5. Create a new application for the Person.
6. Add one of the evidence types that was configured for sharing, Income, for example. Make sure the amount is set to $300 and the start date is set to 1/1/2018.
7. Authorise the application - this should result in an integrated case being created and the Income evidence being shared.
8. On the integrated case, update the shared Income evidence with an Effective Date of 3/1/2018 and an amount of $500 and apply changes.
9. Again on the integrated case, update the Income evidence with an Effective Date of 5/1/2018 and an amount of $700 and apply changes.
10. Create another application case for the Person and add Income evidence with an amount of $1000 and a start date of 7/1/2018.
11. Now go to the Evidence tab on the application case and click on Incoming Evidence.
12. Expand the Income evidence.
13. Select 'Set as Latest of Incoming' from the actions menu on the Existing Evidence side.
14. Select the Income evidence in the modal and click Next.
15. Select Correction and click Next.
16. Update the Effective Date to 1/1/2018.
17. Click Save.
18. Issue: No validations are thrown and the existing evidence is not retained as the latest evidence in the timeline.

Resolution:

A new validation has been added to the final Edit modal in the 'Set as Latest of Incoming' wizard which prevents the user from entering an Effective Date that will result in the evidence being marked as historical in the timeline. That is, it ensures that the existing evidence becomes the latest in the timeline.

PO07984, WorkItem:239783 - Selecting the 'Set as Latest of Incoming' action does not prevent the existing evidence being set as historic evidence

Issue Description:

When choosing the New Version option as the 'Set as Latest of Incoming' action from the existing evidence actions menu, no validations are thrown when the specified Effective Date overlaps with the Incoming Evidence timeline. This means that it's possible to set the existing evidence as something other than the latest in the timeline.
User Interface Impact: No

Steps to Reproduce:

1. From Evidence Sharing under Rules and Evidence in the shortcuts panel, configure evidence sharing between an application case and its associated integrated case, with Trusted Source set to Yes.
2. Login as a caseworker.
3. Register a new Person.
4. Create a new application for the Person.
5. Add one of the evidence types that was configured for sharing, Income, for example. Make sure the amount is set to $300 and the start date is set to 1/1/2018.
6. Authorise the application - this should result in an integrated case being created and the Income evidence being shared.
7. On the integrated case, update the shared Income evidence with an Effective Date of 3/1/2018 and an amount of $500 and apply changes.
8. Again on the integrated case, update the Income evidence with an Effective Date of 5/1/2018 and an amount of $700 and apply changes.
9. Create another application case for the Person and add Income evidence with an amount of $1000 and a start date of 7/1/2018.
10. Now go to the Evidence tab on the application case and click on Incoming Evidence.
11. Expand the Income evidence.
12. Select 'Set as Latest of Incoming' from the actions menu on the Existing Evidence side.
13. Select the Income evidence in the modal and click Next.
14. Select New Version and specify an Effective Date of 2/1/2018 and click Next.
15. Issue 1: The Effective Date is not validated and the final modal screen is displayed.
16. Click Save.
17. Issue 2: No validations are thrown and the newly created timeline on the case is invalid.

Resolution:

A new validation has been added to the 'Set as Latest of Incoming' wizard on the 'Specify an Action' page to prevent the user from specifying an Effective Date that will result in the evidence being marked as historical in the timeline. That is, it ensures that the existing evidence becomes the latest in the timeline. The same validation is also present on the Edit Income modal at the end of the 'Set as Latest of Incoming' wizard.

PO08083, WorkItem:242489 - Unable to add Identifications evidence to a Person from the Incoming Evidence screen

Issue Description:

Logically Equivalent is the process of mapping evidence from one case to another when the evidences are modelled differently on each case. The conditions under which the data is equivalent can vary over time, meaning equivalence across cases may not apply for the full duration of the timeline of evidence. When Trusted Source was set to No, sharing this evidence resulted in sharing all of the timeline of this evidence, incorrectly including the elements that are not logically equivalent. Attempting to action the evidence on the target case resulted in validations as the data was not suitable for the target case.

This is a generic issue for any logically equivalent evidence that can change over time, where conditions of equivalence can vary over this timeline. It is best explained via an example which exists between SSN Details from Insurance Affordability integrated case to Identifications at a Person level. In this example, these are only equivalent when the SSN value is populated. At Person level Identification evidence must have a value populated whereas Insurance Affordability integrated case supports capture of SSN Details without a value. SSN Details without a value indicates that the person has applied for SSN but has not yet received one. During this time, Identifications and SSN Details evidence are not equivalent and therefore it should not be shared to Person level.

With Trusted Source set to No, when sharing a succession of Logically Equivalent evidence where some records in the succession set fail the logically equivalent 'share when' rule, the entire succession set would still get shared to the target case. These records could not be actioned on the target case as the data was not correct/valid there.

User Interface Impact: No

Prerequisite(s):

A Logically Equivalent evidence sharing rule is configured for the Insurance Affordability integrated case SSN Details to Person Record Identifications using the out-of-the-box XML configuration with Trusted Source set to No.

Steps to Reproduce (Insurance Affordability specific example):

1. Login as an Insurance Affordability caseworker.
2. Create a back-dated Insurance Affordability application, with an application date of two months ago, say, where the Person has no SSN, but 'Applied for SSN' is set to Yes.
3. Authorise the application.
4. Navigate to the Insurance Affordability integrated case.
5. Edit the SSN Details to add an SSN Number and an Effective Date of today and unset 'Applied for SSN' so that it is blank.
6. Apply changes.
7. Navigate to the Incoming Evidence screen on the Person.
8. Expand the SSN Details toggle.
9. Select 'Add to Case' from the action menu on the incoming evidence on the left side of the screen.
10. Click Yes on the confirm screen and click Save on the evidence screen.
11. Issue: The evidence does not get added to the case and a validation is thrown indicating that mandatory fields are not set.

Resolution:

The logic has been updated to prevent records being shared when the logically equivalent 'share when' rule evaluates to false.

Technical

Included as standard in evidence sharing is when evidence is shared with the Incoming Evidence list for caseworker review, the entire business object is kept together in order to provide context on the target case. Certain system actions are reconciled at the business object level to achieve this. For example, if the first part of a succession receives an IGNORE_LINKED action and the second part of the succession receives a CASEWORKER_REVIEW action, the entire business object will be updated to set everything to CASEWORKER_REVIEW.

In this logically equivalent scenario, the same logic applied. The first record in the succession failed the XML 'share when' rule, so it got an action of IGNORE_EXPRESSION_RETURNED_FALSE which prevents that record from sharing. The second record in the succession of the SSN Details record got an action of CASEWORKER_REVIEW because Trusted Source is set to No. Since part of the business object has an action of CASEWORKER_REVIEW, the entire business object is updated to have that action. This causes the first part of the evidence succession to share even though it originally received the IGNORE_EXPRESSION_RETURNED_FALSE action. This record cannot be added to the target case from the Incoming Evidence screen as mandatory data is missing, because it was shared incorrectly.
With the updated logic, IGNORE_EXPRESSION_RETURNED_FALSE will never be overwritten by another action, which will prevent incomplete pieces of evidence being shared to a target case.

PO08120, WorkItem:243384 - Clarify the Evidence Sharing guide for Intake

Issue Description:

Sections in the product documentation that explain how evidence sharing works as part of the intake process did not describe in detail what happens when a case member is added to an application case and any evidence that is shared from existing cases at that time is activated. In particular, it did not describe how any further sharing of evidence that would normally be initiated due to the activation of evidence is bypassed and does not occur until the evidence is subsequently shared onto the integrated case after the application is authorized.

User Interface Impact: No

Steps to Reproduce: N/A

Resolution:

The documentation has been updated to describe in more detail how evidence sharing occurs during the intake process. For more information about the functionality, see the following sections:
https://curam-spm-devops.github.io/wh-support-docs/spm/pdf-documentation

WorkItem:244135 - Update with Incoming wizard does not allow a correction to be performed if the incoming evidence start date is already on the existing evidence timeline

Issue Description:

The 'Update with Incoming' correction flow is throwing a validation when the incoming record start date already exists on the current evidence timeline.
**User Interface Impact: **No

Prerequisite(s):

An application case is configured to create an integrated case when authorised. An evidence type, that supports effective dating, is configured on both the application case and integrated case and is enabled for sharing. A sharing configuration exists from the application case to the integrated case for the evidence with Trusted Source set to Yes.

Steps to Reproduce:

1. Login as a caseworker.
2. Register a new Person.
3. Create an application case for the Person.
4. Navigate to the application case and create the configured evidence with a start date of 3/3/2019.
5. Authorise the application.
6. Create another application case for the Person.
7. Navigate to the new application case and create the configured evidence with a start date of 1/1/2019.
8. Edit the newly created evidence and add an Effective Date of 2/2/2019.
9. Edit the same evidence again and add an Effective Date of 3/3/2019.
10. Navigate to the Incoming Evidence screen.
11. Expand the configured evidence.
12. Select 'Update with Incoming' from the actions menu on the Existing Evidence side.
13. Select the configured evidence in the modal and click Next.
14. Select Correction and click Next.
15. Issue: A validation is thrown stating that the incoming evidence record start date already exists in the existing evidence succession.

Resolution:

This validation has been updated to first check the start dates of the two pieces of evidence being corrected. If the incoming record start date matches the start date of the existing record that is being corrected, a validation is no longer thrown.

PO08191, WorkItem:245066 - Received Date from an incoming evidence record is not retained following an 'Update with Incoming' action on an existing evidence record

Issue Description:

When the 'Update with Incoming' action is selected on an existing evidence record in the Incoming Evidence list, the Received Date is not taken from the incoming evidence record, instead the Received Date is taken from the existing evidence.
**User Interface Impact: **No

Steps to Reproduce:

Prerequisite(s):

1. Ensure that the Addresses evidence type is configured against the Integrated Case type used in the scenario below.

Scenario:

1. Login as an administrator.
2. Navigate to Evidence Sharing under Rules and Evidence in the shortcuts panel.
3. Configure a New Sharing Configuration for Addresses between the Person Record and any Integrated Case with Trusted Source set to Yes.
4. Login as a caseworker.
5. Register a new Person.
6. Create an Integrated Case for the Person; The Addresses evidence is automatically shared and activated.
7. Login as an administrator.
8. Navigate to Evidence Sharing under Rules and Evidence in the shortcuts panel.
9. Update the configuration created above and set the Trusted Source to No.
10. Login as a caseworker.
11. Search for the Person registered above and navigate to the Person home page.
12. From the Evidence tab, modify their existing Addresses evidence setting the Received Date to a date in the past and click Save.
13. On the Integrated Case, navigate to the Evidence tab, then click on Incoming Evidence.
14. On the Existing Evidence side of the page, click on the 'Update with Incoming' action for the shared Addresses evidence.
15. Issue: The modify modal does not display the Received Date entered at step 12 above.

Resolution:

This issue has been resolved and the Received Date is now taken from the incoming evidence record for the 'Update with Incoming' step rather than from the existing evidence record.

PO08250, WorkItem:246432 - Evidence is being shared as in-edit and active to a product delivery case

Issue Description:

When evidence is configured to share from an application case to a product delivery case, duplicate evidence records are created on the product delivery case.

User Interface Impact: No

Prerequisite(s):

An application case is configured to create an integrated case and a product delivery case when authorised. An evidence type is configured on both the application case and product delivery case and is enabled for sharing. A sharing configuration exists from the application case to the product delivery case for the evidence with Trusted Source set to Yes. Screens for viewing both active and in-edit evidence are configured on the product delivery case.

Steps to Reproduce:

1. Login as a caseworker.
2. Register a new Person.
3. Create an application case.
4. Navigate to the application and create the configured evidence.
5. Authorise the application.
6. Navigate to the related product delivery case.
7. Issue: There are an active evidence and duplicate in-edit evidence on the case.

Resolution:

This issue has been resolved and evidence is no longer duplicated on the product delivery case during authorisation.

Technical:

During authorisation of an application case, evidence that is configured for sharing is pushed to the target case using the Evidence Sharing Push Workflow. When a person is added to a case, evidence that is configured for sharing is pulled onto the case using the Evidence Sharing Pull Workflow. A push and a pull happening at the same time cause evidence to be duplicated on the target product delivery case. The authorise logic has been updated to prevent a pull from being triggered when evidence is already being pushed from that same authorisation.

Financial Management

PO03429, WorkItem:122574 - A minus payment occurs on the system if financial components are regenerated for a future date where the delivery pattern is different to the current one

Issue Description:

When a third party deduction exists for a period where there are multiple delivery patterns, the financial components generated for the deduction are not split in accordance with those delivery patterns. Only the current delivery pattern is used. This means that when payments are generated in the future for delivery patterns that start in the future, no deductions will occur on those payments as no deduction financial components are generated for those future delivery patterns.

A side effect is that a deduction line item will be generated for that future period with the old delivery pattern. This effectively results in a negative payment as no payment line item exists for the same delivery method in this period, which means the rolling up mechanism will roll up a zero payment with a monetary deduction.

**User Interface Impact: **No
Steps to Reproduce:

1. Login as a caseworker.
2. Register a new Person.
3. Create a new integrated case for the Person.
4. Add a product that has the following delivery patterns associated with it:
   • Weekly By Check In Advance On Monday
   • Weekly By Voucher In Advance On Monday
5. Select 'Weekly By Check In Advance On Monday' when adding the product.
6. Create a certification starting on a Monday and ending on a Sunday covering a period of 12 weeks.
7. Set up a utility deduction from the start date (with no end date) for the nominee (primary client) on the case.
8. Approve and activate the case.
9. At this point 2 financial components should exist on the case, 1 for the payment and 1 for the deduction. Both should be of type CHQ.
10. Pay the case for the first week.
11. Now change the delivery pattern on the case from the start of the second week - change it to 'Weekly By Voucher In Advance On Monday'.
12. At this stage two live financial components will exist, 1 for the payment and 1 for the deduction. Both should be of type VCH.
13. On the same system date, and before any payment runs, go back to the case and update the payment method back to the original payment method from the start of the following (third) week.
14. The following 3 live financial components should exist on the system:
    • 1 payment financial component of type VCH for week 2.
    • 1 deduction financial component of type VCH covering the remaining weeks on the case.
    • 1 payment financial component of type CHQ for week 3.
15. Issue: There is no future deduction financial component by CHQ generated. This means that in week 3, the VCH deduction financial component is generated into a line item and gets rolled up by itself into a negative VCH payment.

Resolution:

The logic for generating third party deduction financial components has been updated to take into account future delivery patterns on the case, thereby resulting in the correct financial components being generated.

PO06023, WorkItem:149232 - Payments incorrectly rolled together across two delivery methods when one of the delivery methods is EFT and where IBAN/BIC is enabled

Issue Description:

When IBAN and BIC functionality is enabled, if a client is receiving payments on two separate products, one by Check and one by EFT, and those payments are issued on the same day, a rolled up payment is issued to the client by Check. This is incorrect. Two separate payments should be issued, one by Check and one by EFT.

User Interface Impact: No

Steps to Reproduce:

Prerequisite(s)

1. Set the system property 'curam.participant.enableibanfunctionality' to 'YES'.

Scenario

1. Login as a caseworker.
2. Register a new Person.
3. Create a bank account for the Person, specifying an IBAN and BIC.
4. Create an integrated case for the Person.
5. Add and activate the necessary evidence on the integrated case.
6. Add a product to the integrated case for the Person with a delivery pattern of 'Weekly By Check In Advance'.
7. Submit, approve and activate the case.
8. Now add a second product to the integrated case with a delivery pattern of 'Weekly By EFT In Advance'.
9. Submit, approve and activate the second case.
10. Run the Generate Instruction Line Items and Generate Instruments batch processes.
11. Issue: Two separate payment instructions should be created, however, only one rolled up Check payment is created.

Resolution:

There was a defect in the rolling up mechanism which prevented the splitting of payments across delivery methods when one of those delivery methods was EFT and IBAN and BIC functionality was enabled. This has been resolved and two separate payments will now be created in the scenario outlined above.

PO08222, WorkItem:245760 - No financial components are generated when using a rules rate target of Employer

Issue Description:

No financial components are generated when the rules rate target is set to Employer for the payable objective in a rule-set. This affects both Classic (non-CREOLE) and CER (CREOLE) rules.
User Interface Impact: No

Steps to Reproduce:

Prerequisite(s) if using a non-CREOLE product:

1. Modify an existing eligibility and entitlement rule-set setting the target (ratetarget attribute) to Employer ('RC4') for one of the payable objectives.
2. For convenience, hard-code the targetid attribute to the participantID of the Employer to be used in the business scenario.
3. Reset the database.

Prerequisite(s) if using a CREOLE product:

1. Modify an existing eligibility and entitlement rule-set setting the target derivation (rateTarget attribute) to Employer ('RC4') for one of the payable objectives.
2. For convenience, hard-code the targetIDTimeline attribute derivation to the participantID of the Employer to be used in the business scenario.
3. Reset the database.

Scenario:

1. Login as a caseworker.
2. Register a new Person.
3. Create an integrated case for the Person.
4. Add a product associated with the modified rule-set above, 'Weekly By Check In Advance'.
5. Add the necessary evidence to make the modified objective eligible for payment.
6. Activate the evidence.
7. Add the necessary certification if the product is certifiable.
8. Add the Employer referenced in the rule-set as a nominee on the case.
9. Assign the payable objective, for whom the target type is Employer, to the nominee from the case start date.
10. Submit, approve and activate the case.
11. Issue: Running the Simulate Payment process reports 'No payments due on this date'. Likewise trying to issue payment either online or in batch will not generate any payments on this case. This is due to no financial components being present on the system for the active case, which does have eligible decisions.

Resolution:

As part of the financial component generation process, the system examines each of the objectives to be made payable by those financial components. For each payable objective, it checks its rate target type. The API that does this catered for rate targets of type Client, Product Provider and Service Supplier. This has now been updated to also cater for targets of type Employer.

Solutions

Income Support

Medical Assistance

PO08003, WorkItem:239868 - Smart Navigator: Application Search keyword not working for Income Support users

Issue Description:

When searching for applications using Smart Navigator, Merative Social Program Management Common Intake applications are not included in the search results.
User Interface Impact: No

Steps to Reproduce:

1. Login as an Income Support caseworker.
2. Register a new Person.
3. Submit a new application for an Income Support product, such as Food Assistance or Cash Assistance.
4. Using Smart Navigator search for the registered person and include the keyword Application.
5. Issue: Merative Social Program Management Common Intake applications such as those for Food Assistance or Cash Assistance are not found.

Resolution:

Consolidated search functionality has now been included that allows Smart Navigator to search for all applications.

Note: This workitem addresses previous Known Issue: 239164

MEDICAL ASSISTANCE

WorkItem:241866 - Person level Address evidence is created as 'Address Unavailable' when an application is submitted and intake resilience is turned on

Issue Description:

When an Insurance Affordability intake application is submitted, the address evidence is being created as 'Address Unavailable' on the Person level evidence for any newly registered people, instead of the address provided during the intake process. This issue only occurs when intake resilience is enabled.

User Interface Impact: No

Steps to Reproduce:

1. Login as a system administrator.
2. Click on the System Configurations workspace.
3. Click on Property Administration under Application Data in the shortcuts panel.
4. Search for the property with the name 'curam.intake.use.resilience'.
5. Set the value of this property to YES and click the Publish page action.
6. Login as an Insurance Affordability caseworker.
7. Register a new Person and start a new application for that Person.
8. Create a second Person on the application who lives at the same address as the primary applicant.
9. Submit the application.
10. Navigate to the newly registered Person.
11. Click on the Evidence tab and select Active Evidence.
12. Issue: The address evidence is marked as 'Address Unavailable' instead of the address of the primary applicant.

Resolution:

Address information for new people added during the intake process will now be created correctly on the participant data case.

Technical:

• During the Insurance Affordability intake process, the address data in the datastore is pre-processed to facilitate the evidence mapping process.
• On the resilient path, however, this pre-processing is happening at a later point. That is, after the Person has been registered and the address created.
• This means that there is effectively no address data to map to the participant data case.
• To resolve, the address pre-processing was moved from curam.healthcare.intake.impl.AddressDataIntakeApplication
  Listener.preMapDataToCuram(IntakeApplication) to curam.healthcare.intake.impl.Address
  IntakeApplicationMapping
  Event.preCreateCasesInCuram(IntakeApplication)
• AddressDataIntakeApplicationListener was unbound as an curam.workspaceservices.intake.impl.IntakeApplication.
  IntakeApplicationEvents implementation.

WorkItem:246410 - Implicit sort expected but not specified in the Insurance Affordability implementation of the PopulateSuccessionSetRuleObjectHook interface

Issue Description:

Insurance Affordability products can propagate evidence to rules timelines using the received date as the succession criteria. When retrieving the records to propagate in the Insurance Affordability implementation of the PopulateSuccessionSetRuleObjectHook interface there was an incorrect assumption made that the records would be ordered. The order of records cannot be guaranteed and the order led to incorrect timelines being propagated which resulted in incorrect rules calculations.

Note:
This issue is only intermittently reproducible in a clustered environment.

User Interface Impact: No

Prerequisite(s):

1. A clustered environment is required to reproduce this issue.
2. Environment property curam.hcr.effectivedate must be set to YES (this indicates that received date will be used as the succession criteria).
3. Set the server date to 4/15/2019.

Steps to Reproduce:

1. Submit a backdated Insurance Affordability Application with the following details:
   • Application Date 1/1/2019.
   • Not a US Citizen. Not a US National.
   • Lawfully Present with any Date of Entry.
   • Supporting Document, I-551 Permanent Resident Card.
   • Supporting Document Details, Alien A1234567 / Card ABC1234567890.
2. Applicant is eligible for Streamlined Medicaid: 1/1/2019 - 12/31/2019.
3. Change in Circumstance:
   • Effective date Citizen Status evidence on the Integrated Case on 4/15/2019. Citizen Status, U.S. Citizen. Immigration Status, blank.
   • Effective date DHSID evidence on the Integrated case on 4/15/2019. Change Document Type to Certificate of Citizenship. Remove Alien Number and Card Number. Add Date of Birth.
   • Activate the evidence.
4. Issue: The applicant may become ineligible on the Streamlined Medicaid Product from 1/1/2019 - 4/14/2019.

Resolution:

This issue has been resolved by the addition of an explicit sort on the records being retrieved for propagation. The timelines are now correctly populated from all evidence records in the succession when propagating to rules using the received date mechanism.

Child Welfare

PO04815, WorkItem:116577 - Intake information is missing from Intake summary section of the Ongoing Case home page

Issue Description:

When an intake of type Inter-jurisdictional is screened in and approved by an intake supervisor, the intake may either be associated to a newly created ongoing case or to an existing ongoing case. When the Inter-jurisdictional intake is associated to an existing ongoing case, if another intake was previously associated to the ongoing case, the other intake no longer displays as expected on the Intake Summary section of the home page of the ongoing case and only the
new Inter-jurisdictional intake is displayed.

User Interface Impact: No

Steps to Reproduce:

Create the Intake:

1. Login as a Child Welfare intake worker.
2. Create a Child Protection Services intake.
3. Click on the Participants tab and use the New Participant action menu to capture a participant with the role of Alleged Victim.
4. Open the intake using the Open Intake tab menu.
5. Click on the Allegations tab and use the New page action to capture an allegation.
6. Click on the Recommendation tab and select the Capture page action menu
7. Record a Screened-In recommendation and click Submit.

Approve the Intake:

1. Login as a Child Welfare intake supervisor and click on the approval task in the Available Tasks pod.
2. On the task home page, click on the Make Decision primary action.
3. Click Approve on the Make Decision modal.
4. Enter comments on the Approve Recommendation page and click Save.

Create the Investigation:

1. Login as a Child Welfare investigator.
2. Click on the task in the Available Tasks pod.
3. Click on the Create Investigation primary action on the task home page.
4. Click Start on the Start Investigation page.
5. On the Investigation home page, click on the Contacts tab and capture a Contact Log.
6. Click on the Allegation tab and select the Dispose row level action.
7. Set the Disposition to Substantiated on the Dispose Allegation page and click Save.
8. Select the Make Recommendation tab action menu.
9. On the Make Recommendation page, select Transfer to Ongoing, enter some comments and click Submit.

Approve the Investigation:

1. Login as a Child Welfare investigation supervisor.
2. Click on the task in the Available Tasks pod.
3. Click on the Approve Recommendation primary action.
4. Click Approve on the Manage Investigation Recommendation page.
5. Enter comments in the Response field of the Approve Recommendation page and click Save.

Create the Ongoing Case:

1. Login as a Child Welfare case worker.
2. Click on the task in the Available Tasks pod to initiate the creation of the Ongoing Case.
3. Click on the Initiate Ongoing Case primary action on the task home page.
4. On the Create Ongoing Case page click Save.
5. Observe that the Ongoing Case home page contains reference to the Child Protection Services intake.

Create the Inter-Jurisdictional Intake:

1. Login as a Child Welfare intake worker.
2. Create a new Inter-Jurisdictional intake for the same participant used above.
3. From the Intake home page, capture a Screened-In recommendation and click Submit.

Approve the Inter-Jurisdictional Intake:

1. Login as a Child Welfare caseworker.
2. Approve the available task for the intake.
3. Login as a Child Welfare case worker.
4. Open the available task and select the existing Ongoing Case and click on Create Ongoing case.
5. Issue: On the Ongoing Case home page, the Inter-Jurisdictional intake has replaced the earlier Child Protection Services intake.

Resolution:

The Inter-Jurisdictional intake no longer replaces the Child Protection Services intake and they are now both displayed in a list.

PO06737, WorkItem:178918 - The Provider pop-up modal associated with a Placement on an Ongoing Case is not populated

Issue Description:

After creating a placement within a case, information about the provider that was selected for the placement can be viewed from the Placements and Placements Requests pages. Currently the Provider modal that is displayed when selecting a provider is not being populated with the details of the provider.

User Interface Impact: No
Steps to Reproduce:

1. Login as a Child Welfare caseworker.
2. From the shortcuts panel, select Register Person and Create Case.
3. Enter the Person details and select to create an Ongoing Case.
4. Click on the Removals and Placement tab and select the New Removal page level action.
5. Enter the mandatory details and click Save and Place.
6. Enter in a Type of Foster Care and set the Change Reason to be 'Initial placement'.
7. Click Next and search for any Provider.
8. Select one from the list and click Finish.
9. Expand the record for the child on the Removals and Placement list page.
10. Click on the Placements tab, and then click on the Provider link.
11. Issue: The pop-up modal is not populated.

Resolution:

The search (SQL) query to fetch the Provider details was formed incorrectly resulting in no records being returned. This has been fixed and the details are now returned and displayed correctly in the pop-up modal. The provider modal is now populated if accessed from either the Removal and Placements tab or the Placement Requests tab.

PO07797, WorkItem:231231 - A Prospect Person is registered after selecting an exact match for an Intake participant when using Internet Explorer 11

Issue Description:

When creating an Intake participant if a match is found to an existing person on the Potential Matches step and exact match is selected then the existing person is set as the Intake participant, otherwise a new Prospect Person is created. When using the Internet Explorer 11 browser, a Prospect Person is incorrectly created after an exact match is selected.

User Interface Impact: No

Steps to Reproduce:

1. Login as a Child Welfare intake worker using the Internet Explorer 11 browser.
2. Select the New Intake link from the Quick Links pod.
3. On the New Intake modal, select the 'Child Protection Services' category.
4. From the Assistant, select the Participants tab.
5. Select New Participants from the page menu and enter information that will result in a match to an existing Person.
6. On the Potential Matches modal, select the Exact option on the Person listed and click Finish.
7. Navigate to the Person Search in the shortcuts panel.
8. Search for the existing Person used in the Intake.
9. Issue: A new Prospect Person has been registered.

Resolution:

This issue has been addressed for Internet Explorer 11, and the correct Person selected as an exact match is attached to the Intake case.

PO06427, WorkItem:234452 - The Intake Reporter Preferred Language defaults to American Sign on the Information Provider home page

Issue Description:

When capturing a Reporter within an Intake, if no match is found for the information entered about the individual on the Reporter Search step of the wizard, a new participant of type Information Provider is registered to represent the individual serving as the Reporter. In this scenario no Preferred Language information can be entered by the user and the value defaults to American Sign. This results in the display of incorrect information when details of the Reporter are viewed on the Information Provider Home page.

User Interface Impact: No

Steps to Reproduce:

1. Login as a Structured Decision Making Child Welfare intake worker.
2. Create a new Child Protection Services Intake.
3. Select the Participants tab and select New Reporter from the action menu.
4. In the Capture Reporter wizard, select the Type as Voluntary and Role as Friend or Neighbor to reproduce the issue.
5. Click Next.
6. Enter the Name and Address of the Reporter and click Next.
7. Click Finish.
8. Select New Participant from the action menu.
9. Enter Name and Role and click Next.
10. Click Finish.
11. Select Open Intake from the tab actions menu.
12. Click on the Participants tab in the Open Intake and select Reporter.
13. Click on the Reporter name link.
14. Issue: On the Information Provider home page, the Preferred Language defaults to American Sign.

Resolution:

This issue has been resolved by adding a conditional cluster in the Capture Reporter wizard which allows for the capturing of a Preferred Language when the Reporter is registered as a new participant of type Information Provider.\