Merative ™ Social Program Management 7.0.11.0 Refresh Pack

Merative ™ Social Program Management is now Cúram ™ by Merative™

Release Notes

Abstract

Merative Social Program Management 7.0.11.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.11.0 is a Refresh Pack.

Introduction

Welcome to the Merative Social Program Management 7.0.11.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.11.0 Refresh Pack release includes new functionality, for detailed information about these new features, see the* What's new in Version 7.0.11.0* topic in the product documentation.

For more information about version 7.0.11.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.

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/spm

Installation

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

The installation steps are as follows:

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
Cúram Enterprise Framework
Cúram Modules
Solutions

Third Party Updates

WorkItem:258901 - Update Browser plug-ins JRE levels used in Microsoft Word Integration

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

WorkItem:258902 - Browser Support Update

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

Case Worker Application Browser Support

Universal Access Application Browser Support

WorkItem:258903 - Tablet Accessibility Support

The certified version of Apple VoiceOver has been updated to iOS 13.4.1. This has been certified against Chrome 85.

WorkItem:261135 - Updating WebSphere Liberty support to version 20.0.0.9

The supported version of WebSphere Application Server Liberty used deploying Merative Social Program Management on IBM Cloud Kubernetes Services and Red Hat OpenShift has been upgraded from 19.0.0.12 to 20.0.0.9.

As part of this upgrade, the LDAP dependency that was introduced as part of the 7.0.10.0 release has been removed.

WorkItem:263328 - Update the version of Apache Commons Codec used in the Merative Social Program Management application

The Apache Commons Codec package contains simple encoders and decoders for various formats such as Base64 and Hexadecimal. In addition to these widely used encoders and decoders, the Commons Codec package also maintains a collection of phonetic encoding utilities.

The library is used in a variety of places for Base64 encoding purposes, including the CDEJ general plug-in infrastructure, the Microsoft (MS) Word Integration functionality, and also in the Rest infrastructure.
The version of Commons Codec used by Merative Social Program Management has now been updated from 1.5 to 1.14. Commons Codec 1.14 contains some bug fixes and a number of improvements.

As a result of this upgrade, the version of the specified Commons Codec JAR has been updated in the following files in the Java Development Environment deliverable.

The changes to the Commons Codec JAR files include:

It should be noted that any references in custom scripts and other artifacts to the versioned JARs should be updated to point to the new versions of the JAR files as specified above.

WorkItem:263632 - Update the version of MQ Long Term Support (LTS) to 9.1.0.5

The supported version of IBM MQ Long Term Support (LTS) used when Merative Social Program Management (SPM) is deployed on Kubernetes has been upgraded from 9.1.0.3 to 9.1.0.5.

SPM customers may obtain IBM MQ certified containers from the IBM Cloud Container Registry for use as a Supporting Program for SPM. Use as a Supporting Program means that IBM MQ certified containers can only be used to process internal JMS messages within SPM.

SPM does not require or support the use of any IBM MQ Advanced features available in the IBM MQ certified containers.

IBM MQ certified container is supported only on SPM Version 7.0.11 and later versions.

WorkItem:263663 - Introduce Support for Merative MQ certified containers on OpenShift

Merative Social Program Management (SPM) now supports Merative MQ certified containers version 9.1.5.0 when containerized and deployed on OpenShift.

SPM customers may obtain Merative MQ certified containers from the Merative Cloud Container Registry for use as a Supporting Program for SPM. Use as a Supporting Program means that Merative MQ certified containers can only be used to process internal JMS messages within SPM.
SPM does not require or support the use of any Merative MQ Advanced features available in the Merative MQ certified containers.

Merative MQ certified container is supported only on SPM Version 7.0.11 and later versions.
For more information, see the What's New section in the documentation, and the associated runbook:

https://merative.github.io/spm-kubernetes/

WorkItem:264148 - Update the version of Apache FOP (Formatting Objects Processor) used in the Merative Social Program Management (SPM) application

Apache FOP is a print formatter driven by XSL formatting objects and an output independent formatter. It is used by the Merative Social Program Management XML Server in the generation of PDF documents.

The version of Apache FOP used by the Merative SPM XML Server has now been updated from 2.3 to 2.5. Apache FOP 2.5 contains some bug fixes and a number of improvements.

As a result of this upgrade, the following changes have been made in the Java Development Environment deliverable.

The changes to the FOP and related JAR files include:

It should be noted that any references in custom scripts and other artifacts to the newly versioned JARs should be updated to point to the new versions of the JAR files as specified above.

WorkItem:265204 - Introduce Support for Red Hat OpenShift

Issue Description:

Merative Social Program Management (SPM) now supports OpenShift version 4.5.

For more information, see the What’s New section in Version 7.0.11.0 of the product documentation and the Containerization of Merative Social Program Management Guide.

WorkItem:265640 - The Cloud Platform details has been moved to the Merative Social Program Management on Kubernetes Runbook

Issue Description:

The Merative Social Program Management (SPM) 7.0.10 and 7.0.11 software prerequisites have been updated to remove the list of technologies documented in the Cloud Platform section. Cloud-Native technologies supported by SPM are detailed in the SPM on Kubernetes Runbook.

For more information refer to https://merative.github.io/spm-kubernetes/prereq/prereq/.

Cúram Enterprise Framework

Dynamic Evidence
Technical Services
Integrated Case Management
Intake
Application Development Environment
Business Services

PO08458, WorkItem:250671 - Narrow text fields within pages are causing truncations and wrapping in fields in multiple pages across Merative Social Program Management

Issue Description:

Text, date, and drop-down values are truncated, text labels are wrapped and fields are not aligned properly in several different pages across the Merative Social Program Management (SPM) business application, including Provider Management, Child Welfare, Income Support, Administration as well as certain core Platform capabilities. The scenarios detailed below, outline the specific pages where this arises.

No

Steps to Reproduce:

Provider Management:
Scenario 1

  1. Login as a Provider Management Resource Manager.
  2. Search for and open an existing Provider.
  3. Click the Credentials tab and select Training.
  4. Create a New Non-Managed Training Program using the page action.
  5. Use the Edit row-level action to modify the training program.
  6. Issue: Registered and Unregistered Training fields are truncated on the Edit Training modal.

Scenario 2

  1. Login as a Provider Management Resource Manager.
  2. Create a new Incident for an existing Provider.
  3. Click the Credentials tab and select Home Studies.
  4. Use the New page action to create a new home study.
  5. Issue 1: Type, Purpose, and Accessor field values are truncated on the New Home Study modal.
  6. Select the New Home Visit row-level action.
  7. Issue 2: Purpose and Conducted By field values are truncated on the New Home Visit modal.
  8. On the Home Studies list page, use the toggle to drill into the detail of the Home Study record.
  9. Select the Home Visits tab to access the home visit.
  10. Select the New Attendee row-level action for the home visit.
  11. Issue 3: Fields are not aligned and the drop-down field values are truncated on the New Attendee modal.

Scenario 3

  1. Login as a Provider Management Resource Manager.
  2. Create a new Incident for an existing Provider.
  3. Click the Credentials tab and select Home Studies.
  4. Use the New page action to create a new home study.
  5. Select the New Assessment row-level action.
  6. Issue 1: Type and Result field values are truncated on the New Assessment modal.
  7. On the Home Studies list page, use the toggle button to display the detail of the Home Study record.
  8. Select the Assessments tab to access the assessment.
  9. Select the Edit row-level action for the assessment.
  10. Issue 2: Type and Result field values are truncated on the Edit Assessment modal.

Scenario 4

  1. Login as a Provider Management Resource Manager.
  2. Create a new Incident for an existing Provider.
  3. Click the Credentials tab and select Home Studies.
  4. Use the New page action to create a new home study.
  5. Select the Edit row-level action.
  6. Issue: Purpose and Conducted By field values are truncated on the Edit Home Study modal.

Scenario 5

  1. Login as a Provider Management Resource Manager.
  2. Open an existing Provide Group.
  3. Click the Credentials tab and select Background Checks.
  4. Use the New page action to create a new background check.
  5. Issue 1: Type, Result, Provider Group Member, and all other date fields are truncated on the New Background Check modal.
  6. Select the New Failure Reason row-level action on the newly created Background Check.
  7. Issue 2: Date and Failure Reason field values are truncated on the New Failure Reason modal.

Scenario 6

  1. Login as a Provider Management Resource Manager.
  2. Search for and open an existing Provider.
  3. Click the Credentials tab and select Specialties.
  4. Use the New page action to create a new specialty.
  5. Issue 1: Speciality drop-down values are truncated and date field values are truncated on the New Specialty modal.
  6. Select the Edit row-level action on the newly created Specialty.
  7. Issue 2: Speciality drop-down values are truncated and date field values are truncated on the Edit Specialty modal.

Scenario 7

  1. Login as a Provider Management Resource Manager.
  2. Search for and open an existing Provider.
  3. Click the Relationships tab and select Provider Participant.
  4. Use the New page action to create a new participant.
  5. Select the Edit row-level action on the newly created Provider Participant.
  6. Issue: Type, From Date, and To Date fields are truncated on the Edit Participant modal.

Child Welfare:

Scenario 1

  1. Login as a Child Welfare caseworker.
  2. Search for an existing person.
  3. Click the Background tab and select Education.
  4. Use the New page action to create a new education.
  5. Create a New Performance for the Education record using the row-level action.
  6. On the Education list page, use the toggle button to display the detail of the Education record.
  7. Select the New Attachment row-level action on Performance Record on the inner list.
  8. Issue: Document type drop-down values are truncated and the Receipt Date field is not aligned on the New Attachment modal.

Scenario 2

  1. Login as a Child Welfare intake worker.
  2. Create a new Child Protection Services intake.
  3. Click the Participants tab and use the New Participant page action to add a new participant.
  4. Add a new Allegation and Capture Recommendation.
  5. Login as a Child Welfare intake supervisor.
  6. Approve the Intake and start the Investigation.
  7. Click the Plan tab and select Services.
  8. Use the New page action to create a new service.
  9. Select the Edit row-level action on the service.
  10. Issue: Client and Nominee field values are truncated on the New Service modal.

Scenario 3

  1. Login as a Child Welfare adoption worker.
  2. Search for an existing person.
  3. Create an Adoption case for the person.
  4. Select Edit from the tab menu.
  5. Issue: Priority field label and value are truncated on the Edit Case modal.

Scenario 4

  1. Login as a Child Welfare adoption worker.
  2. Search for an existing person.
  3. Create an Adoption case for the person.
  4. Click the Prospective Families tab and select Prospective Families.
  5. Use the page action to create a new prospective family.
  6. Select the Capture Recommendation row-level action for the new prospective family.
  7. Issue: Staffing Recommendation field value is truncated on the Capture Staff Recommendation modal.

Scenario 5

  1. Login as an administrator and add existing Milestones for the Adoption case.
  2. Login as a Child Welfare adoption worker.
  3. Search for an existing person.
  4. Create an Adoption case for the person.
  5. Click the Administration tab and select Milestones.
  6. Use the New page action to create a new milestone.
  7. Add a Waiver to the Milestone.
  8. Reject the Waiver.
  9. Issue: Rejection Reason drop-down menu is truncated on the Reject Milestone Waiver Request modal.

Scenario 6

  1. Login as a Child Welfare adoption worker.
  2. Search for an existing person.
  3. Create an Adoption case for the person.
  4. Click the Administration tab and select Milestones.
  5. Use the New page action to create a new milestone.
  6. Issue: Expected Start Date field is truncated and there is too much padding between the filed label and the field value on the New Milestone modal.

Scenario 7

  1. Login as a Child Welfare caseworker.
  2. Search for an existing person.
  3. Click the Background tab and select Physical Characteristics.
  4. Use the New page action to create a new physical characteristic.
  5. Issue 1: Drop-down field values are truncated on the New Physical Characteristic modal.
  6. Select the Edit row-level action on the new physical characteristic.
  7. Issue 2: Drop-down field values are truncated on the Edit Physical Characteristic modal.

Income Support:

Scenario 1

  1. Login as a system administrator.
  2. Search for the property 'curam.evidence.pdc.personenabled' and update its value to NO. Publish the change.
  3. Login as an administrator and un-hide the identity tab for IS Person.
  4. Login as an Income Support caseworker.
  5. Click the Identity tab and select Citizenships.
  6. Use the New page action to create a new citizenship.
  7. Issue: Country and Reason drop-down values are truncated on the New Citizenship modal.

Scenario 2

  1. Login as a system administrator.
  2. Search for the property 'curam.evidence.pdc.personenabled' and update its value to NO. Publish the change.
  3. Login as an administrator and un-hide the identity tab for IS Person.
  4. Login as an Income Support caseworker.
  5. Click the Identity tab and select Citizenships.
  6. Use the New page action to create a new citizenship.
  7. Select the Edit row-level action for the citizenship.
  8. Issue: Country and Reason drop-down values are truncated on the Edit Citizenship modal.

Administration:

Scenario 1

  1. Login as an administrator.
  2. Open an existing service from Provider Management Services.
  3. From the Description section, click the Info Message.
  4. On the Localizable Text modal, click Add Translation.
  5. Issue: Label Language is truncated on the New Text Translation modal.

Scenario 2

  1. Login as an administrator.
  2. Navigate to License Requirements for Training Courses in Provider Management.
  3. Use the New Requirement row-level action to add a requirement to any existing License.
  4. Use the toggle to drill down into the detail of the License that the requirement was added to.
  5. Use the Edit row-level action to modify the new requirement.
  6. Issue: Fields are not aligned on the Edit Training Requirement modal.

Platform application:

Scenario 1

  1. Login as a caseworker.
  2. Register a Person and create an integrated case.
  3. Click the Contact tab and select Attachments.
  4. Select the New page action menu to create a new attachment.
  5. Issue: Document Type drop-down values are truncated on the New Attachment modal and on the Edit Attachment modal.

Scenario 2

  1. Login as a caseworker.
  2. Search for an existing person.
  3. Click the Administration tab and select Roles.
  4. Click Register in New Role page action.
  5. Issue 1: Modal window title has an incorrect heading of 'Register Participant Role.Test'.
  6. Issue 2: Participant Role drop-down values are truncated.

Scenario 3

  1. Login as a caseworker.
  2. Search for an existing person.
  3. Click the Issues and Procedures tab and select Incidents.
  4. Use the New page action to create a new incident.
  5. On the newly created Incident, click the Participants tab and add a participant using the Add Participant page action.
  6. Issue: Participant and Role drop-down values are truncated on the Add Incident Participant modal.

Scenario 4

  1. Login as a caseworker.
  2. Search for an existing person.
  3. Click the Administration tab and select Administrators.
  4. Use the New page action to add a new administrator.
  5. Issue: New Owner drop-down values are truncated on the Set Participant Owner modal.

Scenario 5

  1. Login as a caseworker.
  2. Search for an existing person.
  3. Click Issues and Proceedings tab and select Incidents.
  4. Use the New page action to add a new Incident.
  5. On the newly created Incident, click the Attachments tab.
  6. Select the New page action menu to create a new attachment.
  7. Issue: Document Type drop-down values are truncated and the Receipt Date field is not aligned on the New Attachment modal and on the Edit Attachment modal.

Scenario 6

  1. Login as a caseworker.
  2. Search for an existing person.
  3. Click the Issues and Procedures tab and select Investigations.
  4. Use the New page action to add a new Investigation.
  5. Click the Reference Number of the newly created Investigation.
  6. Click the Contact tab and select Contact Log.
  7. Use the New Contact page action to create a new contact.
  8. Issue 1: Type drop-down values are truncated on the Details page of New Contact wizard.
  9. On the Narrative page of the New Contact wizard, enter the text and click the Back button.
  10. Issue 2: Date, Type, and Author fields are not aligned.
  11. Continue with the creation of the Contact, enter a contact narrative, and click the Next button.
  12. Issue 3: Registered Participant drop-down values are truncated on the Participants page of New Contact wizard.
  13. Complete the creation of the contact.
  14. Select the Edit row-level action for the contact.
  15. Issue 4: Type drop-down values are truncated on the Edit Contact modal.

Resolution:

These issues have been resolved. The width of the impacted screens in Provider Management, Child Welfare, Income Support, Administration, and Platform have been adjusted to prevent the truncation of fields and drop-down menus, as well as wrapping of labels and values.

Dynamic Evidence

Evidence Validations

PO08901, WorkItem:263660 - Sometimes the application is not presenting the correct text for dynamic evidence screens.

Issue Description:

Under certain circumstances, the application is not presenting the correct text to be displayed for the cluster and field labels on dynamic evidence screens.

User Interface Impact: No
Steps to Reproduce:

  1. Login as a French-speaking caseworker.
  2. Register a new Person.
  3. Click the evidence tab.
  4. Use the New page action to create a new address.
  5. Issue: Some of the fields on the page are presented in English.

Resolution:

This issue is now resolved and the correct text is always displayed for the label and cluster labels on dynamic evidence screens.

Technical:

During the Dynamic UIM display phase, the context values are now set with the current user's active request, user preferences locale, and default time zone. The context ensures any plug-ins invoked from the current servlet request will have the correct context information by all plug-ins invoked from the current thread during the current request.

The Java class that has been updated is:

EVIDENCE VALIDATIONS

WorkItem:260089 - A verification informational message prevents a user from continuing when creating SSN Identifications for a person

Issue Description:

A verification informational message can display when creating evidence with verifications configured for it. An example is when creating Identifications of type Social Security number evidence for a person which prevents the user from continuing. The message is 'The following items require verification:'. Another example is on validating mailing addresses when registering a prospect person.

**User Interface Impact: **No

**Related WorkItem(s): **259181

Prerequisite(s):

  1. Login as a system administrator.
  2. Navigate to Code Tables under Application Data in the shortcuts panel.
  3. Search for the name: VerReqUsageName.
  4. Select the New Item row-level action.
  5. Enter the following details:
    • Item Name: Participant Data Case
    • Technical ID (code): VRUN9999
  6. Click Save.
  7. Publish the changes using the page action.
  8. Login as an administrator.
  9. Navigate to Configured Verifications under Verifications in the shortcuts panel.
  10. Click on SSNID under Personal.
  11. Select the Edit page action and change the Evidence Type from SSN Details to Identifications.
  12. Click Save.
  13. Click on Social Security Card under items, which are under SSNID in the tree view.
  14. Select the Edit page action and change Usage Type to Shared, Level to 1, and check Mandatory.
  15. Click Save.
  16. Click on requirements under SSNID and select New from the page action menu. Enter the following details:
    • Name: Requirement 1
    • Level: 1
    • From Date: 1/23/2020
    • Minimum Items: 0
    • Reverification Mode: Reverify Always
    • Supplied By Client: Unchecked
    • Mandatory: Checked
    • Due Days: 0
    • Warning Days: 0
  17. Click Save.
  18. Click on Requirement 1 under Requirements.
  19. Select Apply To from the page action menu. Enter the following details:
    • Name: Participant Data Case
    • Applies To: Select 'Non Case Data' in the drop-down and use the search to select Participant.
  20. Click Save.

Steps to Reproduce:

  1. Login as a caseworker.
  2. Register a new Person.
  3. Click on the Evidence tab.
  4. Select New from the page action menu and create Identifications evidence with the following details:
    • ID Reference: any 9-digit SSN
    • Type: Social Security Number
    • Preferred: Checked
  5. Click either Save & Exit or Save & Next.
  6. Issue: The following informational message is displayed and the user cannot continue 'The changes that you have made may affect the verification information recorded for the following item(s):'.

Resolution:

There was an issue in the code that was unintentionally throwing the verification informational at the point of creating the evidence when it should be ignored at that stage. This has now been resolved.

Technical Services

PO08900, WorkItem:264367 - An unhandled server exception is thrown when a business method (facade) is invoked before a database connection has been established

Issue Description:

An unhandled server exception is thrown when a business method (facade) is invoked before a database connection has been established in the server infrastructure. This results in no data being returned to the calling client page and may cause the application to become unusable.

User Interface Impact: No

Note:

This issue only surfaced intermittently in the SPM application. There are no consistent series of steps that can be documented to reproduce it. The following is a general pattern that can cause the issue.

Prerequisite(s):

  1. A class member variable for a code-table entry exists on a facade object.

Steps to Reproduce:

  1. Call the facade containing the code-table entry via a client page.
  2. Issue: An attempt will be made to validate the code-table value when the facade object is being created, but before it is invoked. Since no database connection has yet been established, an unhandled server exception is thrown and no data is returned to the client page.

Resolution:

The server infrastructure has been updated to ensure a database connection is established before any other server logic is executed. The server data will now be returned to the client page requesting it.Technical:

The java class that was updated to resolve this issue is:

Integrated Case Management

Eligibility & Entitlement

PO08488, WorkItem:251605 - An error occurs when Provider or Provider Group is selected as a role for a person

Issue Description:

A caseworker can register a person in a new role, such as an external party, for example. As part of registering the person in a new role, an error occurs if the caseworker selects the role as provider or provider group.

User Interface Impact: No

Steps to Reproduce:

  1. Login as a caseworker.
  2. Register a new Person.
  3. Click on the Administration tab and select Roles.
  4. Select the Register in New Role page action.
  5. Choose Provider or Provider Group in the Participant Role drop-down and click Next.
  6. Issue: An error is encountered and the caseworker cannot complete the action.

Resolution:

While provider and provider groups can also be registered in the role of a person, this is intended to occur within the Provider Management module where resource managers are responsible for determining when this should occur. Because of this, caseworkers were not intended to be able to indicate that a person should also play the role of a provider or provider group. These code-table items, which were being displayed incorrectly as options when selecting another role for a person, no longer appear in the Participant Role drop-down.

PO08675, WorkItem:251756 - A blank communication file is downloaded when the Open Microsoft Word row-level action is selected for an existing communication

Issue Description:

Microsoft Word communications documents are not being downloaded correctly when selecting the Open Microsoft Word row-level action for existing communications. A blank communication file is being downloaded instead of the Microsoft Word document.

User Interface Impact: No

Prerequisite(s):

Install the Chrome plug-in:

  1. Install the IBMCuramWordIntegrationAssistant.msi which is located in IBM/Curam/Development/CuramCDEJ/lib/curam/installers.
  2. Install the 'Merative SPM File Edit Native Messaging Bridge' extension from the Chrome Web Store.
  3. Set a JRE_HOME Environment variable to point to the location of an installed JRE.
  4. Create a new browser profile in Chrome, as described here: https://support.google.com/chrome/answer/2364824.
  5. Switch to the new profile in Chrome.

Create and upload the Microsoft Word Template:

  1. Open Microsoft Word and create a test document.
  2. Login as a system administrator.
  3. Click on the Systems Configurations tab.
  4. Select Microsoft Word Templates under Communications in the shortcuts panel.
  5. Click on the New page action to create a new Microsoft Word Template.
  6. Upload the previously saved Microsoft Word document using the Browse button.
  7. Fill in the Name and Template ID fields.
  8. Select All Communication and All Communications, respectively, from the Category drop-down fields.
  9. Click Save.

Steps to Reproduce:

  1. Login as a caseworker.
  2. Register a new Person.
  3. Click on the Client Contact Tab and select Communications.
  4. From the page actions menu select New Microsoft Word.
  5. Ensure the Client is Correspondent checkbox is selected and click Next.
  6. Add a subject and either select an address or enter address details.
  7. Select the newly created Microsoft Word Template from the Template Name drop-down. Click on Save and the Microsoft Word document will be launched in Microsoft Word. If asked, click ‘Yes’ to allow your browser to interact with this control.
  8. Update this document and save and close it.
  9. When the communication is created select the Open Microsoft Word row-level action.
  10. Issue: A blank communication file is downloaded.

Resolution:

This issue has been resolved and now the file download mechanism for Microsoft Word documents retrieves the correct Microsoft Word document from the system.

ELIGIBILITY & ENTITLEMENT

WorkItem:264549 - A duplicate component assignment is being displayed for a case nominee

Issue Description:

When updating the delivery method on a product delivery case by adding a new delivery pattern, the nominee component assignments page displays duplicate component entries.

**User Interface Impact: **No

Prerequisite(s):

  1. Login as an administrator.
  2. Click on Product Delivery Cases under Cases in the shortcuts panel.
  3. Click on any benefit product and open its home page.
  4. Click on the Financial tab and select Delivery Patterns.
  5. Use the New page action to create a delivery pattern with the following details:
    • Name = Yearly by EFT
    • Delivery Method = EFT
    • From Date = Current Date
    • Delivery Frequency = Yearly on the January 1st
    • Cover Pattern = Issue in advance

Steps to Reproduce (Generic):

  1. Login as a caseworker.
  2. Register a new Person.
  3. Click on the Care and Protection tab.
  4. Click on the New page action to create an integrated case that relates to the product referenced in the prerequisite(s).
  5. Create product delivery and select any weekly delivery pattern.
  6. Click on the Financials tab of the product delivery case and select Delivery Patterns.
  7. Click on the New page action to create a new delivery pattern. Select the Yearly by EFT delivery pattern and check the From Case Start Date field.
  8. Click Save.
  9. Select Components from the left-hand page group navigation.
  10. For any of the components listed, choose the Assign to Nominee row-level action.
  11. On the modal, select Yearly by EFT for the Nominee and check the From Case Start Date field.
  12. Click Save.
  13. Select Nominees from the left-hand page group navigation.
  14. Expand the client name and click on the Component Assignments inline page.
  15. Issue: There are duplicate rows for the component with the Yearly by EFT delivery pattern.

Resolution:

Duplicate component assignments are no longer displayed for a nominee when a new delivery pattern is added to a product delivery case.\

Technical:

The service layer call which retrieved nominee component assignments contained duplicate component entries. This has been corrected to only return unique entries.

Intake

WorkItem:261552 - Verification pages are referencing deprecated facade operations rather than more up to date facades which return additional data

Issue Description:

The pages that list verifications on the Income Support Application are calling deprecated facade operations. These pages should call newer facades that return the same information as before as well as a new attribute for each verification, verifiableDataItemNameXMLOpt, which controls an icon on the user interface to indicate if a proof document is outstanding.
Note:

This issue was noticed during the integration of the new Submitted Documents Review feature on the Universal Access Responsive Web Application, which allows citizens to upload on the portal proof documents for any outstanding verifications they might have. As part of this feature, there is now a new 'Submitted Documents for Review' cluster on the verifications list pages. This cluster requires the additional data above to be returned to display the relevant information about the submitted verification proof documents.

User Interface Impact: No

Steps to Reproduce (Generic):

  1. Login as an Income Support intake worker.
  2. Register a new Person.
  3. Create and submit a new Income Support application for the person.
  4. Click on the Evidence tab and select Verifications.
  5. Issue: The page displaying outstanding verifications calls a deprecated facade, which does not return the necessary data to support the new Submitted Documents Review feature.
  6. Now click on the All navigation tab.
  7. Issue: The page displaying all verifications calls a deprecated facade, which does not return the necessary data to support the new Submitted Documents Review feature.

Resolution:

The verification client pages that display both outstanding and all verifications have been updated to reference newer facade operations. The new information returned from these facades for each verification, verifiableDataItemNameXMLOpt, is required to support the new Submitted Documents Review feature. More information on this new feature can be found in the What's new section of Product documentation and PDFs.

Technical:

The verification client pages that were updated are listed below, together with the facade operations they now call.

One additional change in the above facades was that the mandatory indicator which signifies if a verification is required or not has been updated from a boolean to a localizable string in the new facades. This is to support verification waivers where the values are Yes/No/Bypassed.

Application Development Environment

Client Development EnvironmentServer Development Environment

WorkItem:262321 - Introduction of a new parameter for the 'stopserver' and 'restartserver' build commands to allow a force shutdown cycle of a Weblogic application server instance

A new parameter has been introduced to allow a 'force shutdown' cycle of a Weblogic application server instance when using the 'stopserver' and 'restartserver' build commands. If the parameter is set when running the 'restartserver' and 'stopserver' commands against a Weblogic application server instance, the application server will move immediately to the shutdown state rather than allowing a graceful shutdown for ongoing application server processing to complete against the application server.

This build parameter should be used only in exceptional circumstances as the application server will not complete its normal shutdown process. An example would be a testing scenario where an abrupt shutdown of a Weblogic application server instance is needed to complete a test objective.
The 'force shutdown' cycle of a Weblogic application server instance can be started by setting the parameter '-Dwls.force.stop' to a value of 'true', 'yes' or 'on' when using the build command syntax as shown below when stopping or restarting a Weblogic application server instance:

As part of this change the following files have been updated:

WorkItem:264300 - Documentation Security Guide updated to include SSO information

Single Sign-On (SSO) is an authentication process that allows users to access many applications with one set of credentials. Once users log into one application, they do not have to log in repeatedly to access other applications that are part of one application domain.

SPM Lab Services have to create custom processes and documentation for each project that uses SSO, so the Security Guide needs to include SSO content from other sections of the documentation.

The SPM 7.0.10 documentation has SSO topics in different sections:
https://curam-spm-devops.github.io/wh-support-docs/spm/pdf-documentation

SSO content is now consolidated in the 7.0.11 release into the Security Guide:
https://curam-spm-devops.github.io/wh-support-docs/spm/pdf-documentation

Where relevant, there are links from the Kubernetes and Universal Access sections to the security section. For example, see:
https://curam-spm-devops.github.io/wh-support-docs/spm/pdf-documentation

CLIENT DEVELOPMENT ENVIRONMENT

Accessibility
Widgets

PO08713, WorkItem:256842 - Microsoft Word Integration feature hides the actual application exception (AppException) thrown during the generation of a document

Issue Description:

If an application exception (AppException) is encountered when using the Microsoft (MS) Word Integration feature, the AppException may be hidden and the following generic message shown in its place:

'The page you have requested is not available. One possible cause for this is that you are not licensed for the necessary Merative Social Program Management module. If that is the case, you can use the User Interface administration screens to remove these links.'

**User Interface Impact: **No

Prerequisite(s):

Update the server code to throw an application exception

  1. Modify / override curam.core.facade.impl.Communication#getWordTemplateDocumentAndData() to throw any existing AppException and perform a server build.

Note: This change needs to be reverted once the issue is reproduced.

Check for the existence of a Microsoft Word Template

  1. Login as a system administrator.
  2. Navigate to Microsoft Word Templates under Communications in the shortcuts panel.
  3. If none exists, use the New page action to create a new one.
  4. Provide a Name, Template ID, and browse and upload a Microsoft Word template file.
  5. Select the appropriate Locale and click Save.

Steps to Reproduce:

  1. Login as a caseworker.
  2. Register a new Person.
  3. Click on the Client Contact tab and select Communications.
  4. Use the New Microsoft Word page action to create a new MS Word Communication.
  5. Specify the details and click Save.
  6. Issue: The message displayed is not the application exception message that has been thrown inside the getWordTemplateDocumentAndData() facade operation.

Resolution:

The FILE_EDIT widget has been updated to display the correct error message when an application exception is encountered during the creation of an MS Word Communication.

PO08053, PO06531, WorkItem:258261 - Not all static content is included in the static content zip

Issue Description:

The relocation of static content, CSS, JavaScript, fonts, and images, for example, to a separate web server allows for specific cache-control response headers to be set for this content. Setting a cache-control response-header provides an instruction to the browser to cache this content for some time, the aim of which is to reduce network traffic and improve performance.
Previously, when the target build zip-static-content -Dstatic.content.zip=<myzipfile.zip> was invoked, not all static content was included within the generated zip. The following is a list of content that was included:

WebContent/**/*.html
WebContent/**/*.htm
WebContent/CDEJ/**/*.png
WebContent/CDEJ/**/*.gif
WebContent/CDEJ/**/*.jpg
WebContent/CDEJ/**/*.jpeg
WebContent/CDEJ/**/*.ico
WebContent/CDEJ/**/*.css
WebContent/CDEJ/**/*.js
WebContent/CDEJ/**/*.svg

as well as all content within the following folders (and sub-folders):

WebContent/CDEJ/jscript
WebContent/CDEJ/themes
WebContent/Images
WebContent/genImages
WebContent/themes

User Interface Impact: No
Steps to Reproduce:
N/A

Resolution:

The target build zip-static-content -Dstatic.content.zip has been updated to have more generic filtering to ensure all relevant static content is included in the generated static content zip. The following content is included in the .zip file:

WebContent/**/*.htc
WebContent/**/*.html
WebContent/**/*.htm
WebContent/**/*.bmp
WebContent/**/*.cur
WebContent/**/*.gif
WebContent/**/*.ico
WebContent/**/*.jpeg
WebContent/**/*.jpg
WebContent/**/*.mov
WebContent/**/*.png
WebContent/**/*.psd
WebContent/**/*.svg
WebContent/**/*.swc
WebContent/**/*.swf
WebContent/**/*.eot
WebContent/**/*.ttf
WebContent/**/*.woff
WebContent/**/*.woff2
WebContent/**/*.as
WebContent/**/*.js
WebContent/**/*.vbs
WebContent/**/*.css
WebContent/**/*.less
WebContent/**/*.json

Note: This is a release note for a fix that was delivered in 7.0.10.

WorkItem:261685 - Scrollbar not appearing on pop-up menus or combo boxes after opening them for a second time in Internet Explorer 11

Issue Description:

When using the Internet Explorer 11 browser, a pop-up menu or a combo box may contain a scrollbar when opened. These scrollbars are not appearing when the pop-up menu or combo box is reopened after being closed for the first time.

User Interface Impact: No

Steps to Reproduce:

  1. Change the screen resolution to 1366 x 768.
  2. Login as a caseworker using the Internet Explorer 11 browser.
  3. Register a Person.
  4. Click on the Tab Action Menu on the Person home page.
  5. Notice that there is a scrollbar to view options at the end of the menu.
  6. Click anywhere else in the application and click to open the Tab Action Menu again.
  7. Issue: The scrollbar on the menu is no longer visible and a user cannot scroll to the hidden options.

Resolution:

This issue is now resolved and the scrollbars are now present when the pop-up menu or a combo box is reopened after being closed for the first time.
Technical:

The Javascript related to pop-ups has been updated to prevent the overflow and height styling attributes being overwritten when a pop-up is reopened. The Javacript file that was updated is:

WorkItem:261686 - Pop-up windows which appear after clicking on an informational icon in a context panel are not opening in the Internet Explorer 11 browser

Issue Description:

Pop-up windows displayed after clicking on an informational icon in a context panel are not opening in the application when using Internet Explorer 11. This issue can occur throughout Merative Social Program Management.
User Interface Impact: No

Steps to Reproduce:

  1. Login as a caseworker using Internet Explorer 11.
  2. Register a new Person.
  3. Create a Special Caution for the person and notice an icon appears in the context panel.
  4. Click on the Special Caution icon in the context panel.
  5. Issue: The pop-up window does not open.

Resolution:

The Javascript related to pop-up has been updated to enable pop-up windows to open when an informational icon in a context panel is clicked in Internet Explorer 11.

Technical:

The following Javascript file has been updated:

WorkItem:262575 - Introduce precompile support for Liberty deployments

Issue Description:

Precompiled JSP's are not included in the EAR content on an Merative Websphere Liberty build. This causes the initial response times of pages to be quite slow.

**User Interface Impact: **No
Steps to Reproduce:
N/A

Resolution:

In order to ensure faster page times, JSP's are precompiled as part of the Merative Websphere Liberty build. This is achieved by including the 'precompilejsp' target within the liberty build scripts.

ACCESSIBILITY

WorkItem:239996 - The contrast between the text and the background colors in the Login, Logout, Cancel and Try Again buttons on the Login screen fails the minimum color contrast requirement

Issue Description:

The contrast between the text and the background colors in the Login, Logout, Cancel and Try Again buttons on their respective JSP pages on the Login screen do not meet the minimum color contrast requirement for users with color vision deficiency.

User Interface Impact: No

Steps to Reproduce:

  1. At login on the logon page at the following URL <serverName>/Curam/logon.jsp, observe the color contrast for the Login button.
  2. At logout on the logout page at the following URL <serverName>/Curam/logout.jsp, observe the color contrast for the Logout button.
  3. On the same page, observe the color contrast of the Cancel button.
  4. At login failure on the logon page at the following URL <serverName>/Curam/logonerror.jsp, observe the color contrast for the Try Again button.
  5. Issues: The color contrast for the Login, Logout, Cancel, and Try Again buttons do not meet the minimum color contrast requirement.

Resolution:

The CSS for the font and the background colors for the Login, Logout, Cancel, and Try Again buttons have been updated to meet the color contrast requirement.
Technical:

These are the files that have been updated:

TI/client/Generator/resources/css/external-infrastructure-css.properties

For the new color definitions:

1) New variable infrastructure_primary-submit-buttons_color = #1d3649 added for the font color of the buttons
2) New variable infrastructure_secondary-hover-submit-buttons_color = #7cc7ff added for the hover color of the Login, Logout and Try Again buttons
3) New variable infrastructure_secondary-hover-cancel-button_color = #c7c7c7 added for the hover color of the Cancel button

TI/client/Generator/resources/css/css-variables.properties

Adding mapping for the new variables defined above as follows:

1) infrastructure_logon_page_button_font-color=$infrastructure_primary-submit-buttons_color
2) infrastructure_logon_page_cancel-background-hover=$infrastructure_secondary-hover-cancel-button_color
3) infrastructure_logon_page_button_hover-background=$infrastructure_secondary-hover-submit-buttons_color
Value for the background color of the Cancel button:

1) infrastructure_logout_page_cancel_background=#aeaeae

TI/client/CoreInf/CuramCEDJ/lib/curam/web/themes/curam/css/curam_login_page.css

For using the new variables:

1) $infrastructure_logon_page_button_font-color
2) $infrastructure_logon_page_button_hover-background
3) $infrastructure_logon_page_cancel-background-hover

PO08092, WorkItem:242665 - Decorative icons used for Issue, Items to Verify and Evidence in Edit at the top of the Evidence Dashboard page are being announced by the screen reader

Issue Description:

On the Evidence Dashboard in-page navigation tab of an integrated case, the decorative icons used for Issue, Items to Verify, and Evidence in Edit at the top of the page are being announced by the screen reader, which can be confusing to the impaired user when they read out of a context.

User Interface Impact: No

Steps to Reproduce:

  1. Enable a screen reader.
  2. Login as a caseworker.
  3. Register a new Person.
  4. Create any type of integrated case for the person.
  5. Click on the Evidence tab.
  6. Issue: The screen reader reads the text for each of the 3 decorative icons at the top of the Evidence Dashboard page.

Resolution:

The in-page navigation tabs that contain the decorative icons used for Issue, Items to Verify and Evidence in Edit at the top of the Evidence Dashboard page are now no longer read out by the screen reader.

PO08553, WorkItem:247839 - List toggle buttons are not visible across the entire application when high contrast mode is enabled on a Windows operating system

Issue Description:

When high contrast mode is enabled on a Windows operating system, the toggle button to expand and collapse items in a list is not visible across the entire application. As a result, the toggle image for collapsing and expanding list rows is not conveyed on the screen to an impaired user.
**User Interface Impact: **No

Steps to Reproduce:

  1. On the Windows operating system, search for the High Contrast settings.
  2. Enable high contrast mode.
  3. Use Internet Explorer.
  4. Login as a caseworker.
  5. Register a new Person.
  6. Click on the Client Contact tab and select Notes.
  7. Use the New page action to create a New Note.
  8. Issue: The toggle icon next to a note in the list is not visible regardless of whether the note is expanded or not.

Resolution:

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

Technical:

This issue was resolved by updating the Java, JavaScript, and CSS code on expandable lists. The toggle button image on a list row is now specified directly in the HTML of the page, rather than through CSS.

WorkItem:250370 - The Citizen Context Viewer (CCV) link in the Primary Client column is not announced correctly by the screen reader

Issue Description:

When a screen reader user navigates to the Cases cluster of an integrated case, the Citizen Context Viewer (CCV) link in the Primary Client column is not announced correctly. There is no label to indicate what the link is for.

User Interface Impact: No

Prerequisite(s):

  1. The Cases cluster on the integrated case home page must contain a link to the CCV in the Primary Client column.

Steps to Reproduce (Generic):

  1. Enable a screen reader.
  2. Login as a caseworker.
  3. Register a new Person.
  4. Click on the Care and Protection tab and select Cases.
  5. Use the New page action to create an integrated case.
  6. Add a product to the integrated case.
  7. Navigate to the Primary Client column of the Cases list on the integrated case home page.
  8. Issue: When tabbing to the CCV link, the content of the link is not announced correctly by the screen reader.

Resolution:

The Javascript related to updating the labels of links within lists has been updated so when a screen reader user navigates to the Cases cluster of an integrated case, the Citizen Context Viewer (CCV) link in the Primary Client column is announced correctly as 'Launch Citizen Context Viewer, Row 2 Link Graphic'.

PO08537, WorkItem:252807 - The column headers on the context panels list view of an integrated case fail the minimum color contrast requirement

Issue Description:

In Merative Social Program Management (SPM), the column headers (Members, Relationship, Age) of an integrated case's context panels list view display in a light gray color which fails the minimum color contrast requirement.
User Interface Impact: No
Related Work Item(s): 256480 (APAR no. PO08609)

Steps to Reproduce:

  1. Login as a caseworker.
  2. Create an integrated case with 4 participants.
  3. Click on the list view icon from the context panel.
  4. Issue: The font color used for the column titles does not meet the color contrast accessibility requirements.

Resolution:

The font color of the header text in the case member list view of an integrated case has been updated to respect the color contrast ratio. This issue was addressed by the code changes made as part of APAR PO08609.

PO08584, WorkItem:254390 - Buttons on the context panel of an investigation case to switch between a list view and a photo view are not visible when high contrast mode is enabled

Issue Description:

When creating an investigation case in Child Welfare, the button icons on the context panel to switch between a list and a photo view are not visible when high contrast mode is enabled on Microsoft Windows OS.

User Interface Impact: No

Steps to Reproduce:

  1. Enable high contrast mode on Microsoft Windows OS.
  2. Login as a Child Welfare Structured Decision-Making intake worker.
  3. Create an intake and add 3 participants, 2 as an Adult and 1 as an Alleged Victim.
  4. Select the Open Intake tab menu option to open the intake case.
  5. Use the New Assessment tab menu option to create an assessment.
  6. Select No or None as the answer to all questions except for one.
  7. Click on the Allegations tab and select New to create a New Allegation.
  8. Select the Alleged Victim, the Unknown Maltreater check-box, the Type, and click Save.
  9. Click on the Recommendation tab and use the Assess row-level action to assess the allegation from the Response Priority cluster.
  10. Select Submit from the page action menu to submit the recommendation.
  11. Click on the Administration tab and select Tasks.
  12. Open the newly created task by clicking on the Task ID hyperlink.
  13. Click on the Make Decision link and Approve the recommendation.
  14. Click on the Intake Home link in the Supporting Information cluster to navigate back to the intake.
  15. Click on the Administration tab and select Tasks.
  16. Click on the task to start an investigation.
  17. Click on the Create Investigation primary action.
  18. Select the 3 persons and click on Start.
  19. Issue: Observe that the buttons to display the list or photo view are not visible.

Resolution:

This issue was resolved by updating the JavaScript and CSS code for the button icons. The image for the icons is now specified directly in the HTML of the page, rather than through CSS. These buttons can now be viewed when high contrast mode is enabled.
Technical:

The following files have been added:

The following files have been changed:

PO08598, WorkItem:254726 - The screen reader does not inform the impaired user when in-page navigation links are disabled when using Internet Explorer 11

Issue Description:

The screen reader does not inform the impaired user when in-page navigation links are disabled, resulting in different information being conveyed to both users and impaired users when using Internet Explorer 11 (IE11).

User Interface Impact: No
Steps to Reproduce:

  1. Enable a screen reader using IE11.
  2. Login as an administrator.
  3. Click on the Administration Workspace and select Tabs under User Interface in the shortcuts panel.
  4. Locate and click on the SDMIntakeAssistant tab link.
  5. Select the Navigation Bar tab.
  6. Delete the page ChildServicesSDM_listAllegationsFromAssistant.
  7. From the page action menu, select New Folder.
  8. Enter 'Allegations' as the ID and Title.
  9. Uncheck the Dynamic Indicator and click Save.
  10. From the folder action menu, select New Page.
  11. Enter ID and Title as 'Allegations'.
  12. Set the page ID to ChildServicesSDM_listAllegationsFromAssistant, which is the one that was deleted above.
  13. Check Dynamic indicator and click Save.
  14. Click on Publish link from under User Interface in the shortcuts panel to publish the changes.
  15. Login as a Child Welfare Structured Decision-Making caseworker.
  16. Create a new Intake.
  17. Navigate to the Allegations in-page tab.
  18. Tab to the Allegations link.
  19. Issue: The screen reader does not announce that the link is disabled.

Resolution:

This issue is resolved and the screen reader will now announce to the user that the link is disabled.

Technical:

The JavaScript code controlling tab navigation has been updated and now the disabled in-page navigation links are announced by the screen reader.

PO08627, WorkItem:254965 - The summary content of tables with headers is announced incorrectly by a screen reader when using Internet Explorer 11

Issue Description:

When a supported screen reader is used and a visually impaired user navigates to a table with headers, the screen reader announces the default summary content of tables as 'Table for formatting purpose only' when using Internet Explorer 11 (IE11).

Note:

All of the reported instances of this issue occur in Child Welfare.

User Interface Impact: No

Steps to Reproduce (Child Welfare):

Scenario 1:

  1. Start a screen reader.
  2. Login as a Child Welfare caseworker using IE11.
  3. Register a new Person.
  4. Click on the Background tab and select Education.
  5. Issue: The screen reader announces the table on the Education page incorrectly.

Scenario 2:

  1. Start a screen reader.
  2. Login as a Child Welfare caseworker using IE11.
  3. Register a new Person.
  4. Click on the Background tab and select Employment.
  5. Issue: The screen reader announces the table on the Employment page incorrectly.

Scenario 3:

  1. Start a screen reader.
  2. Login as a Child Welfare caseworker using IE11.
  3. Register a new Person.
  4. Click on the Background tab and select Gang Affiliation.
  5. Issue: The screen reader announces the table on the Gang Affiliation page incorrectly.

Scenario 4:

  1. Start a screen reader.
  2. Login as a Child Welfare caseworker using IE11.
  3. Select Register Person and Create Case under Cases in the shortcuts panel.
  4. Enter person details and select Ongoing Case in the Type drop-down.
  5. Click Save.
  6. On the Ongoing Case, click on the Contact tab and select Contact Logs.
  7. Issue: The screen reader announces the table on the Contact Logs page incorrectly.

Scenario 5:

  1. Start a screen reader.
  2. Login as a Child Welfare caseworker using IE11.
  3. Select Register Person and Create Case under Cases in the shortcuts panel.
  4. Enter person details and select Ongoing Case in the Type drop-down.
  5. Click Save.
  6. On the Ongoing Case, click on the Administration tab and select Related Cases.
  7. Issue: The screen reader announces the table on the Related Cases page incorrectly.

Scenario 6:

  1. Start a screen reader.
  2. Login as a system administrator using IE11.
  3. Click on Property Administration under Application Data in the shortcuts panel.
  4. Enter 'curam.evidence.pdc.personenabled' in the Name field and click Search.
  5. Use the Edit Value row-level action to update the value of the returned property to NO and click Save.
  6. Use the Publish page action to publish the changes.
  7. Login as a Child Welfare caseworker using IE11.
  8. Register a new Person.
  9. Click on the Identity tab and select Alternate Names.
  10. Issue: The screen reader announces the table on the Alternate Names page incorrectly.

Scenario 7:

  1. Start a screen reader.
  2. Login as a system administrator using IE11.
  3. Click on Property Administration under Application Data in the shortcuts panel.
  4. Enter 'curam.evidence.pdc.personenabled' in the Name field and click Search.
  5. Use the Edit Value row-level action to update the value of the returned property to NO and click Save.
  6. Use the Publish page action to publish the changes.
  7. Login as a Child Welfare caseworker using IE11.
  8. Register a new Person.
  9. Click on the Identity tab and select Alternate IDs.
  10. Issue: The screen reader announces the table on the Alternate IDs page incorrectly.

Resolution:

This issue is now resolved and a screen reader no longer announces the content of tables with headers incorrectly as it is not necessary information for visually impaired users.

Technical:

A javascript page generator file was updated to prevent a screen reader from announcing the summary content of a table with headers. This is a generic fix and will address every instance of this problem, not just for the examples provided above.

PO08636, WorkItem:255265 - Menu icon is not displayed on the home page in high contrast mode on the Windows operating system

Issue Description:

When high contrast mode is enabled on a Windows operating system (OS), the application menu icon is not visible in the application banner of the home page.

User Interface Impact: No

Prerequisite(s):

  1. Change the screen resolution to 1366x768.
  2. On a Windows operating system, search for the High Contrast settings.
  3. Enable high contrast mode.

Steps to Reproduce:

  1. Open the application with an Internet Explorer 11 browser.
  2. Login as any user.
  3. View the user home page.
  4. Issue: The application menu icon is not visible in the application banner of the home page.

Resolution:

The issue has been resolved by updating the relevant CSS styling. The application menu icon is now visible in the application banner.

Technical:

Reduced the padding values in curam_application_banner.css to prevent div-overflow on resizing and updated the background image to an image tag on the application menu icon to fix high contrast issues.

PO08637, WorkItem:255409 - Screen reader not reading the labels for drop-downs on the Invite Hearing Attendee modal

Issue Description:

The label for the type field which corresponds to the drop-down displaying attendee options on the Invite Hearing Attendee page is not announced by the screen reader causing an accessibility issue for the impaired user.
**User Interface Impact: **No

Steps to Reproduce:

Configure the Appeal Process:

  1. Login as an administrator.
  2. Navigate to Appeal Processes under Case in the shortcuts menu.
  3. Use the New page action to create an Appeal Process with the following details:
    • Type = Hearing
    • Start Date = current date
    • Time constraints = default settings but specify 5 as the number of days for each
    • Assign to any product delivery

Create the product delivery and appeal case:

  1. Login as a caseworker.
  2. Register a person.
  3. Create an instance of the integrated case associated with the product delivery selected in the Appeal Process above.
  4. From this integrated case, create an instance of the product delivery.
  5. Close the product delivery.
  6. From the tab menu on the product delivery, select New Case Appeal.
  7. Specify the Appellant and Respondent in the first page of the New Case Appeal wizard and click Next.
  8. Click Save.

Manage the appeal case:

  1. Enable a screen reader.
  2. Login as an appeals hearing official.
  3. Click on Appeal under Searches in the shortcuts menu.
  4. Specify the Appellant's name and the Appellant Type and click Search.
  5. Click on the Case Reference hyperlink of the appeal returned.
  6. Navigate to the Items Under Appeal tab and Approve the appeal using the row-level action.
  7. Click on the Hearings tab.
  8. Use the Schedule Hearing page action to schedule a telephone hearing.
  9. Search for Hearing Official and set the time for the hearing.
  10. Ensure to select the Appellant Attend check-box.
  11. Click Save.
  12. Open the newly created hearing.
  13. Click on the User Attendees tab and select the Invite User page action.
  14. Search for any user and select them.
  15. Issue: On the Invite User Attendee page, the screen reader does not announce the label for the drop-down.

Resolution:

A label for the type field which corresponds to the drop-down displaying attendee options was added to the Invite Hearing Attendee page and now the context for this field is announced by the screen reader.
Technical:

The UIM that was updated is:

PO08639, WorkItem:255410 - The description text above the comments field on the intake modify participant details page is not read by the screen reader

Issue Description:

The description text above the comments field on the intake modify participant details page is not announced by the screen reader.
User Interface Impact: No
Steps to Reproduce:

  1. Enable a screen reader.
  2. Log in as a Child Welfare intake worker.
  3. Create a new Child Protection Services intake.
  4. Select the Participants tab and click on the New Participant page action.
  5. Add the necessary details to create a new participant.
  6. Edit the participant.
  7. Use the tab key to navigate to the comments field.
  8. Issue: The description text for the comments field is not announced by the screen reader.

Resolution:

A label for the comments field was added to the intake modify participant details page and now the description text above the comments field is announced by the screen reader.

Technical:

The UIM that was updated was:

PO08640, WorkItem:255411 - The labels for the Component Category and Component Type drop-downs are not read by the screen reader when using Internet Explorer 11

Issue Description:

The labels for the Component Category and Component Type drop-downs used across the application are not announced by a screen reader when using Microsoft Internet Explorer 11 (IE11). This can confuse a visually impaired user while navigating through these drop-downs.

User Interface Impact: No

Steps to Reproduce:

  1. Enable a screen reader with IE11.
  2. Log in as an administrator.
  3. Navigate to Service Plans using Shortcuts panel.
  4. Create or open an existing Back to Work Service Plan.
  5. Click on the Milestones in-page navigation tab.
  6. Add a new or existing milestone.
  7. Select the Edit row-level action to update the milestone details.
  8. Issue: The screen reader does not read the labels for the Component Category and the Component Type drop-down boxes on the Edit Milestone Association page.

Resolution:

This issue is now resolved and the screen reader now reads the labels for the Component Category and Component Type drop-downs.

Technical:

The AjaxSelectBoxRenderer class was updated to output the Component Category and Component Type drop-down elements with the HTML markup required to ensure their labels will be read by a screen reader.

PO08638, WorkItem:255416 - The screen reader is not reading the label of the Type field displaying attendee options on Edit Hearing Attendee modal

Issue Description:

The label for the Type field displaying attendee options on the Modify Hearing Attendee page is not announced by the screen reader causing an accessibility issue for the impaired user.

User Interface Impact: No

Steps to Reproduce (Generic):

Configure the Appeal Process:

  1. Enable a screen reader.
  2. Log in as an administrator.
  3. Navigate to Appeal Processes under Case in the shortcuts menu.
  4. Use the New page action to create an Appeal Process with the following details:
    • Type = Hearing
    • Start Date = current date
    • Time constraints = default settings but specify 5 as the number of days for each
    • Assign to any product delivery

Create the product delivery and appeal case:

  1. Login as a caseworker.
  2. Register a person.
  3. Create an instance of the integrated case associated with the product delivery selected in the Appeal Process above.
  4. From this integrated case, create an instance of the product delivery.
  5. Close the product delivery.
  6. From the tab menu on the product delivery, select New Case Appeal.
  7. Specify the Appellant and Respondent in the first page of the New Case Appeal wizard and click Next.
  8. Click Save.

Manage the appeal case:

  1. Log in as an appeals hearing official.
  2. Click on Appeal under Searches in the shortcuts menu.
  3. Specify the Appellant's name and the Appellant Type and click Search.
  4. Click on the Case Reference hyperlink of the appeal returned.
  5. Navigate to the Items Under Appeal tab and Approve the appeal using the row-level action.
  6. Click on the Hearings tab.
  7. Use the Schedule Hearing page action to manually schedule a telephone hearing.
  8. Search for Hearing Official and set the time for the hearing.
  9. Ensure to select the Appellant Attend check-box.
  10. Click Save.
  11. Open the newly created hearing.
  12. Click on the User Attendees tab and select the Invite User page action.
  13. Search for any user and select them.
  14. Select any value in the drop-down and click Save.
  15. Edit a User Attendee using the row-level action.
  16. Issue: On the Edit Hearing Attendee page, the screen reader does not announce the label for the drop-down.

Resolution:

****A label for the Type field, which corresponds to the drop-down displaying attendee options, was added to the Edit Hearing Attendee page and now the context for this field is announced by the screen reader.

Technical:

The UIM that was updated is:

WorkItem:256380 - The date picker widget is losing focus when tabbing between the close button and drop-down menu to select the month in Internet Explorer 11

Issue Description:

When using Internet Explorer 11 (IE11), the date picker widget is losing focus when tabbing between the close button and the drop-down menu to select a month.

User Interface Impact: No

Steps to Reproduce:

  1. Log in as a caseworker.
  2. Open the search person page.
  3. Open the date picker.
  4. Press Shift and Tab keys to focus on the close button.
  5. Issue: The focus is lost between the close button and the drop-down menu.

Resolution:

The focus is now moving consistently when tabbing between the close button and the drop-down menu to select a month from the date picker.

WorkItem:257127 - The browser tab title does not update correctly on pages within in-page navigation tabs when an error message is thrown

Issue Description:

When navigating through in-page navigation tabs across the application, the browser tab titles are not updating correctly to indicate the presence of error message(s).

User Interface Impact: No

Steps to Reproduce:

  1. Log in as a Child Welfare intake worker.
  2. Create a New Intake.
  3. Click on the Participants tab and use the New Participant page action to add a participant.
  4. In the shortcut panel, select Intakes to be Completed.
  5. Click on the hyperlink of the newly created intake.
  6. Click on the Contacts tab.
  7. Click on the Search in-page navigation tab.
  8. Run a blank search.
  9. Issue: A validation error is thrown but the browser tab title is not updating to reflect the presence of an error message on the page.

Resolution:

This issue is now resolved and now the browser tab titles are updated to indicate the presence of error messages within in-page navigation tabs.
Technical:

Updates were made to the util.setBrowserTabTitle javascript function and now the browser tab title indicates when there are error messages present within in-page navigation tabs.

PO08741, WorkItem:258517 - A delay in setting the focus to the first form field in Internet Explorer 11 is causing scrolling issues on search screens and pop-up modal screens

Issue Description:

In the Microsoft Internet Explorer (IE) 11 browser, there is a delay before focus is set to the first form field when a search page or pop-up modal page loads. If a user scrolls immediately after the page loads, or after performing a search, the page moves from the current position to the position of the field which has been focused on.

The delay in setting the focus is required to trigger Forms Mode in the JAWS screen reader and to ensure that the initial editable field which receives focus after page load is interactive and available for data entry.

User Interface Impact: No

Steps to Reproduce:

Scenario 1:

  1. Log in as a caseworker using Microsoft Internet Explorer (IE) 11.
  2. Register a Person.
  3. Navigate to the Evidence tab on the person page and add new Relationship evidence.
  4. When the modal opens, immediately scroll down the page.
  5. Issue: After a small delay, the page moves from the current position to the position of the field which has received focus.

Scenario 2:

  1. Log in as a caseworker using Microsoft Internet Explorer (IE) 11.
  2. Click on the Cases and Outcomes workspace tab.
  3. Select Person under Searches in the shortcuts panel.
  4. On the person search page, populate the necessary search fields to return a large number of results.
  5. When the search results are returned, immediately scroll to the bottom of the page.
  6. Issue: After a small delay, the page moves from the current position to the position of the search button after a user performs a search.

Resolution:

In the Microsoft Internet Explorer (IE) 11 browser, the delay in setting focus to the first form field when a search page or pop-up modal page loads has been reduced. If a user scrolls immediately after the page loads or after performing a search, the user's scrolling action is not impacted by the first form field receiving focus.

Please note, if a screen reader user using JAWS loads a page and Forms Mode is not automatically triggered for the initially focused field, and therefore the field is not interactive, a user can press the TAB key and then the SHIFT-TAB key to trigger Forms Mode on the first editable field.

WIDGETS

PO08737, WorkItem:256938 - Microsoft Word Integration feature not working in Google Chrome if the client has more than one Chrome profile

Issue Description:

When using the Google Chrome browser and the Microsoft (MS) Word integration feature, sometimes MS Word does not launch properly if the client has more than one Chrome profile set up.

User Interface Impact: No

Prerequisite(s):

  1. Install the IBMCuramWordIntegrationAssistant.msi which is located in IBM/Curam/Development/CuramCDEJ/lib/curam/installers.
  2. Set a JRE_HOME Environment variable to point to the location of an installed JRE.
  3. Create a new browser profile in Chrome, as described here: https://support.google.com/chrome/answer/2364824.
  4. Install the 'Cúram File Edit Native Messaging Bridge' extension from the Chrome Web Store under each profile.
  5. Switch to the new profile in Chrome.

Steps to Reproduce:

  1. Login as a system administrator.
  2. Navigate to Microsoft Word Templates under Communications in the shortcuts panel.
  3. Choose a sample template that you would like to edit through the application.
  4. Set the Category to be All Communication - All Communications and click Save.
  5. Login as a caseworker.
  6. Register a Person.
  7. Click on the Client Contact tab and select Communications.
  8. From the page action menu select New Microsoft Word.
  9. On the first modal, check the Client is Correspondent check-box and click Next.
  10. In the next modal, fill in the required fields and select the Microsoft Word Template created previously.
  11. Click Save.
  12. Issue: Microsoft Word fails to open.

Resolution:

The Cúram File Edit Native Messaging Bridge assumed that the Chrome profile was called Default. When there is more than one profile, they are named Profile 1, Profile 2, etc. The bridge has been fixed to properly identify the correct Chrome profile when attempting to launch Word.

WorkItem:261305 - Microsoft Word integration does not work when static content is enabled

Issue Description:

When Merative Social Program Management (SPM) is built with a static content server specified, the Microsoft (MS) Word File Edit widget does not work. When a user tries to save a document based on the configured template, the File Edit widget modal does not open and the content written by the user appears in the page iFrame instead.

User Interface Impact: No

Prerequisite(s):

  1. Enable static content by setting the STATIC_CONTENT_SERVER element in curam-config.xml, perform a build, and deploy the application in a supported Application Server.
  2. The user must use a Windows operating system (OS) and ensure the JDK is 1.8.x.

Steps to Reproduce:

Create a Microsoft (MS) Word template that will be used to create the word document

  1. Login as a system administrator.
  2. Navigate to Microsoft Word Templates under Communications in the shortcuts panel.
  3. Use the New page action to create a new template.
  4. Provide a Name, Template ID, and browse and upload the MS Word template created above.
  5. Select the appropriate Locale and click Save.

Create a correspondence using the newly configured template

  1. Login as a caseworker.
  2. Register a new Person.
  3. Click on the Client Contact tab and select Communications.
  4. Use the New Microsoft Word page action to create a new MS Word Communication, ensuring the 'Client is Correspondent' checkbox is checked.
  5. Specify the details and click Save.
  6. Issue: The File Edit widget modal does not open and its content is loaded in the parent iframe instead. MS Word does not open because the required resources are not included from the static content server.

Resolution:

The File Edit widget has been updated to correctly include all required resources from the static content server.

SERVER DEVELOPMENT ENVIRONMENT

Miscellaneous
Transaction Management

MISCELLANEOUS

WorkItem:260743 - Move the properties.jar file to a shared class loader for Liberty

Issue Description:

There are examples where the client application needs to access properties contained within the properties.jar file. One such example is when testing scenarios that involve changes over time.

Property files packaged in the properties.jar file are not accessible by client-side Java code when running on Merative WebSphere Liberty only. This is most notable when testing 'time travel' scenarios using the 'curam.test.override.date' property.
User Interface Impact: No

Steps to Reproduce:
NA

Resolution:

The properties.jar file is relocated from the CuramServerCode.ear to the shared resources directory to be handled by the shared classloader in Merative WebSphere Liberty.

TRANSACTION MANAGEMENT

WorkItem:263634 - Introducing support for persistent timers to enable the download of JMXStatistics in Kubernetes

Issue Description:

JMX Statistics in Merative Social Program Management (SPM) are used by developers to monitor the performance of the application. In Kubernetes, JMS producers and consumers did not store timer-based JMX statistics. As a result, customers would not be able to access data when monitoring or investigating application performance in a Kubernetes environment.

**User Interface Impact: **No

Steps to Reproduce:
N/A

Resolution:

For more information on configuring JMX Statistics in a Kubernetes environment refer to the 'Monitoring performance using JMX statistics' section in the SPM on Kubernetes Runbook, release 20.10.0:


https://merative.github.io/spm-kubernetes/monitoring/jmx-statistics-performance-monitoring/

Business Services

Calendaring/Scheduling

CALENDARING/SCHEDULING

PO08692, WorkItem:256899 - Incorrect error message is displayed when trying to invite attendees to a meeting

Issue Description:

A user can invite attendees to an already scheduled meeting. On the Invite Attendees modal if the user selects attendees from the Invite Users, Invite Clients or Invite Other Participants lists, and does not use the Attendee search for selection, an incorrect error message is displayed.

User Interface Impact: No

Steps to Reproduce (Generic):

  1. Login as a caseworker.
  2. Select Register Person and Create Case under Cases in the shortcuts panel.
  3. Enter person details and select any integrated case in the Type drop-down.
  4. Click Save.
  5. On the integrated case click on the Events tab.
  6. Select the inline List View tab.
  7. Use the New Meeting page action to create a new meeting.
  8. Select the Invite Attendees row-level action on the new meeting activity.
  9. Select the checkbox for a person listed in any of the Invite Clients, Invite Users, or Invite Other Participants lists.
  10. Click on the Add button.
  11. Issue: The error message 'The attendee you have chosen does not match the selected attendee type' is displayed.

Resolution:

This issue is now resolved. The logic has been updated to check if the Attendee field value, as well as type, has been provided. Previously only the type was checked and this always defaulted to some value even if no Attendee of that type was selected.

Cúram Modules

Outcome Management
Universal Access
Intelligent Evidence Gathering
Evidence Broker
Financial Management

Outcome Management

PO08395, WorkItem:249786 - The contents of the Visitation Plan context panel are not being printed out correctly

Issue Description:

Outcome Plans contain visitation plans which are developed to specify and describe planned interactions that occur between clients and visitors. The contents of the Visitation Plan context panel are not being printed correctly. When the context panel page is printed, the contents are misaligned and do not reflect what is shown on the screen.

User Interface Impact: No
Steps to Reproduce:

  1. Login as a Child Welfare caseworker.
  2. Register two people and create an Ongoing case for one of them.
  3. Navigate to the Ongoing case and create an Outcome Plan.
  4. Add the second person as a participant to the Outcome Plan.
  5. Create a Visitation Plan.
  6. Open the Visitation Plan and print the page using the print icon in the content panel.
  7. Issue: When the context panel page is printed, the contents are not being printed out correctly.

Resolution:

The print styling for the Visitation Plan has been updated and when the Visitation Plan context panel is printed, the contents of the printed page reflect what is shown on the screen.

Universal Access

Administration

ADMINISTRATION

PO07119, WorkItem:195194 - CitizenWorkspacePurgeDataProcessStream batch process throws a Null Pointer Exception

Issue Description:

When the CitizenWorkspacePurgeDataProcess batch process runs using both a chunker and a streamer, the streamer reports a Null Pointer Exception and the batch process fails. This batch process is used to remove any temporary data from the system that was created by generated users. If the batch process cannot complete successfully, this temporary data will not be deleted.
**User Interface Impact: **No
Prerequisite(s):

  1. Login as a public citizen on the portal. Note: There is no need to log in or create an online account.
  2. Start but don't complete a screening. This will create data to purge.

Steps to Reproduce:

  1. Login as a system administrator and click on the System Configurations tab.
  2. Click on Property Administration under Application Data in the shortcuts panel.
  3. Enter 'curam.citizenworkspace.purge.transient.dont.run.stream' in the Name field and click Search.
  4. For the result returned, use the Edit Value row-level action to change the value from NO to YES.
  5. Use the Publish page-level action to publish the changes.
  6. Invoke the Batch launcher to execute the chunker
    • build runbatch -Dbatch.program=curam.citizenworkspace.facade.intf.CitizenWorkspacePurgeDataProcess.process -Dbatch.username=SYSTEM -Dbatch.parameters="instanceID=[instanceID],processingDate=[current date]"
  7. Invoke the Batch launcher to execute the streamer
    • build runbatch -Dbatch.program=curam.citizenworkspace.facade.intf.CitizenWorkspacePurgeDataProcessStream.process -Dbatch.username=SYSTEM -Dbatch.parameters="instanceID=[instanceID],processingDate=[current date]"
  8. Issue: The batch process fails to complete due to a Null Pointer Exception being thrown.

Resolution:

This issue has been resolved and now the CitizenWorkspacePurgeDataProcess completes successfully without throwing a Null Pointer Exception, and any temporary data that was created by generated users is deleted.
Technical:

See the documentation for more information on invoking batch processes -

Intelligent Evidence Gathering

Player

WorkItem:262448 - Universal Access Responsive Web Application: Unhelpful error message logged for an invalid question ID

Issue Description:

The error message 'Domain definition initialization failed' is logged when an IEG script contains an invalid question ID, which doesn't help to identify the problem. This issue affects users of the Universal Access Responsive Web Application only.

User Interface Impact: No

Steps to Reproduce:

  1. Update an IEG script to contain an invalid question ID.
  2. Navigate to an IEG page with the invalid question ID.
  3. Issue: Observe the following error in the error log: 'Domain definition initialization failed.'

Resolution:

A meaningful error message that contains the invalid question ID reference is now logged when an invalid question ID is used in an IEG script: 'The question id '%1s' is invalid.'

WorkItem:262827 - Universal Access Responsive Web Application: Hidden clusters are displayed on IEG summary pages when the grouping-id attribute is set

Issue Description:

Hidden clusters are incorrectly displayed on IEG summary pages when the grouping-id attribute is set.
**User Interface Impact: **Yes

Prerequisite(s):

  1. Update an IEG script to contain grouped clusters on the summary page where a second cluster is defined inside a condition.

Steps to Reproduce:

  1. Apply for a benefit by using the IEG script and provide input details for questions so that the defined condition is not met.
  2. Issue: Observe that hidden grouped clusters are displayed on the summary page.

Resolution:

This issue is now resolved and hidden clusters are no longer displayed on IEG summary pages when the grouping-id attribute is set.

WorkItem:262879 - Universal Access Responsive Web Application: Unable to set min/max value restriction to IEG_MONEY domain definition

Issue Description:

Unhandled server exception is thrown when an IEG script page contains a question where the data type is set to a domain based on IEG_MONEY and where the domain's minimum, maximum, or both values, are set.
User Interface Impact: No

Steps to Reproduce:

  1. Update an IEG schema to contain a domain based on IEG_MONEY and with minimum, maximum, or both, values set.
  2. Update an IEG script to contain a question where its data type is set to the newly defined domain.
  3. Navigate to the IEG page where the new question is defined.
  4. Issue: Observe that an unhandled server exception is thrown.

Resolution:

This issue is now resolved. An IEG page loads successfully now when it contains a question whose data type is set to a domain based on IEG_MONEY, where the domain's minimum, maximum, or both values, are set.

WorkItem:263174 - Universal Access Responsive Web Application: Control questions don’t work in expressions when they are not on the same IEG page

Issue Description:

An unhandled server exception is thrown when IEG pages contain conditional expressions that reference control questions that are defined on a different page.
**User Interface Impact: **Yes

Prerequisite(s):

  1. Update an IEG script to contain a conditional expression that references a control question that is defined on a different page.

Steps to Reproduce:

  1. Execute the updated IEG script with the new conditional expression.
  2. Issue: Observe that an unhandled server exception is thrown.

Resolution:

IEG pages load successfully when the pages contain conditional expressions that reference control questions that are defined on a different page. The conditional expression is calculated correctly.

WorkItem:263707 - Universal Access Responsive Web Application: IEG script domains are not updated on IEG schema update

Issue Description:

Domain changes are not reflected in an IEG script after schema import with overwrite option.

User Interface Impact: No

Steps to Reproduce:

  1. Update an IEG schema to contain a domain based on IEG_MONEY and with minimum, maximum, or both, values set.
  2. Update an IEG script to contain a question where its data type is set to the newly defined domain.
  3. Navigate to the IEG page where the new question is defined.
  4. Issue: Observe that the correct minimum and\or maximum validations are displayed.
  5. Update the same domain with different minimum and\or maximum values and import schema with overwrite option.
  6. Navigate to the IEG page where the new question is defined.
  7. Issue: Observe that domain minimum and\or maximum validations are based on old values.

Resolution:

This issue is now resolved. Domain changes are reflected in an IEG script after schema import with overwrite option.

WorkItem:263953 - Universal Access Responsive Web Application: Child code-table name in a code-table hierarchy is not translated

Issue Description:

The child code-table name in a code-table hierarchy is not translated when a locale other than the default English locale is selected for an IEG page that contains a question with a code-table hierarchy.
User Interface Impact: No

Steps to Reproduce:

  1. Translate a code-table hierarchy.
  2. Update an IEG script to contain a question with that code-table hierarchy.
  3. Navigate to the IEG page that contains the question with the code-table hierarchy.
  4. Change the page locale.
  5. Issue: Observe that the child code-table name in the code-table hierarchy is not translated.

Resolution:

The child code-table name in a code-table hierarchy is now translated when a locale other than the default English locale is selected for an IEG page that contains a question with a code-table hierarchy.

PLAYER

PO07818, WorkItem:107581 - Information collected via list questions in previous pages is being lost when navigating past a read-only page in Intelligent Evidence Gathering scripts

Issue Description:

In Intelligent Evidence Gathering (IEG) scripts, when a non-read-only list question is used to gather information, and that list question is then subsequently displayed on a read-only page, the information that was supplied to the non-read-only list question is lost when navigating past that read-only page.

User Interface Impact: No

Prerequisite(s):

To reproduce this issue, a custom IEG script needs to be produced based on the following criteria or similar:

  1. An initial question page that allows the user to register a person.
  2. A second question page with a non-read-only list question, related to the registered person.
  3. A third question page with the same read-only list question, related to the registered person.
  4. A fourth summary page, displaying the same non-read-only list question, used in the second and third pages.

Steps to Reproduce:

  1. Run the custom IEG script.
  2. On the initial question page register a person.
  3. Click Next.
  4. On the second question page check one or more of the checkboxes associated with the non-read-only list question.
  5. Click Next.
  6. On the third question page check if the list question information is passed to this read-only page.
  7. Click Next.
  8. Issue: On the fourth summary page the information that was supplied to the non-read-only list question is lost.

Resolution:

In IEG scripts, when a non-read-only list question is used to gather information, and that list question is then subsequently displayed on a read-only page, the information that was supplied to the non-read-only list question is retained when navigating past that read-only page.
Technical:

The following Java class has been updated to evaluate the read-only expression of a list question before clearing it's related entities:

PO06344, WorkItem:153528 - Updating the exception trace when evaluating an IEG expression on an IEG condition fails

Issue Description:

The IEG condition element can be used to instruct the IEG Engine whether or not to display a given element. It does this by evaluating an expression specified on the condition as true or false based on the answers to some previously asked questions. If the expression cannot be evaluated as true or false, an exception is thrown. This exception is vague and more detail should be provided regarding why the expression could not be evaluated.

User Interface Impact: No

Prerequisite(s):

  1. Configure a custom IEG script with two question pages. The second question page should be inside a condition, and this condition should check for the value of an attribute on an entity that does not exist on the datastore.

Steps to Reproduce:

  1. Launch the custom IEG script.
  2. Click Next to navigate to the second question page.
  3. Issue: A blank validation message is thrown on the screen. An error message describing the expression as invalid is displayed in the application server logs.

Resolution:

This issue has been resolved by displaying more detail in the application server logs about why an expression is invalid.

Note:

An example of how the error may have been displayed previously is:

SEVERE: Malicious code filtered: "expression" from string "The expression 'Entity.attribute=="Example"' is invalid."

An example of how the error may be displayed now is:

SEVERE: Malicious code filtered: "expression" from string "The expression 'Entity.attribute=="Example"' is invalid. No such attribute 'attribute' in entity 'Entity'".

Technical:

The Java classes that were updated are:

PO08420,PO05814, WorkItem:250288 - Read-only values within a conditional cluster are cleared when navigating from their question page

Issue Description:

For an assessment question page containing a conditional cluster, any questions within the conditional cluster that are read-only will lose their values when the user navigates to the next page.

User Interface Impact: No

Steps to Reproduce:

  1. Configure a custom IEG script that has a previously answered read-only question within a conditional cluster.
  2. Launch your custom IEG script.
  3. Answer the question which will later be displayed as read-only within the conditional cluster.
  4. Navigate to the question page where the answered question is displayed as read-only within the conditional cluster.
  5. Click Next.
  6. Issue: The previously answered read-only question within the conditional cluster has lost its value.

Resolution:

This issue has been resolved by ensuring that each read-only question within a conditional cluster maintains its value upon navigating away from its question page.

Note:

A workaround was previously added to the Health Care Reform Change Of Circumstance script definition to ensure read-only data was preserved. Now that the underlying issue has been fixed, this workaround is no longer needed and has been removed.

WorkItem:255481 - Any input field which was dynamically enabled by the value in a drop-down is not being disabled when that drop-down becomes disabled

Issue Description:

When the value of a checkbox is used to enable/disable a drop-down field in an Intelligent Evidence Gathering (IEG) script, if this value is subsequently used to enable another input field, unchecking the checkbox should disable the drop-down field which should subsequently disable the input field. However, the input field remains enabled.

**User Interface Impact: **No
Prerequisite(s):

To reproduce this issue, configure a custom IEG script definition question page to run in the caseworker application containing the following:

  1. A checkbox input field.
  2. A dynamically enabled/disabled drop-down field based on the value of the checkbox.
  3. A dynamically enabled/disabled input field based on the option selected in the drop-down field.

Steps to Reproduce:

  1. Launch the custom assessment script.
  2. Check the checkbox to enable the drop-down field.
  3. Select the value in the drop-down field to enable the next input field.
  4. Uncheck the checkbox.
  5. Issue: The drop-down becomes dynamically disabled, but the input field does not.

Resolution:

The javascript executed to dynamically enable and disable input fields has been updated to ensure any input fields dynamically enabled by the value in a drop-down are disabled when the enabling drop-down becomes disabled.

Technical:

The javascript class that was updated to correct this behavior is:

PO08755, WorkItem:259210 - The Employer Sponsored Coverage Information page title text overlaps with the Print link when using Internet Explorer 11

Issue Description:

While applying for Insurance Affordability benefit, the Employer Sponsored Coverage Information page title text overlaps with the Print link when using the Internet Explorer 11 browser. This happens only when the page title is too long to fit in a single line.

User Interface Impact: No

Steps to Reproduce (Solution-specific):

  1. Login as an administrator.
  2. Navigate to the Application Resources link in the Intelligent Evidence Gathering section of the shortcuts panel.
  3. Select Property from the Category drop-down menu and click Search.
  4. Locate HealthCareCW_V1_Intake_ESCQuestionnairePage on the list.
  5. Select the Download row-level action.
  6. Update the property in the downloaded file, as follows:
    • ESCQuestionnairePage.Title=Additional Information for Access to any other Employer-Sponsored Coverage
  7. Select the Edit row-level action.
  8. Select the Browse button and choose the updated properties file.
  9. Publish the change to the properties file.
  10. Login as an Insurance Affordability caseworker.
  11. Register a Person.
  12. Select New Application from the tab menu on the person.
  13. Starting filling out all the required data for the applicant.
  14. Add a spouse as an additional household member - the primary applicant and spouse should be tax filers, filing jointly.
  15. Add income information of type Wages and Salaries, $50,000 annually for the primary applicant only.
  16. On the 'Additional APTC Program Information' page, select both primary applicant and spouse for the answer to the question:
    • 'Please choose any of the people below who are either enrolled on or eligible for employer-sponsored coverage. The access to coverage could be either through their own employment or as an individual related to the employee.'
  17. Navigate to the next page.
  18. Issue: The Employer-Sponsored Coverage Information page title text overlaps with the Print link.

Resolution:

The styling related to the positioning of the links in the IEG page title bar has been updated so the Employer-Sponsored Coverage Information page title text no longer overlaps with the Print link when the title is long and when using the Internet Explorer 11 browser.

WorkItem:261196 - When completing an assessment through the Citizen Workspace Application, any input field which was dynamically enabled by the value in a drop-down is not being disabled when that drop-down becomes disabled

Issue Description:

An issue can be seen when completing an Intelligent Evidence Gathering (IEG) assessment through the Citizen Workspace Application when the value of a check-box is used to enable or disable a drop-down field. If this value is subsequently used to enable another input field, upon unchecking the check-box, it should disable the drop-down field, which should subsequently disable the input field. However, the input field remains enabled.

User Interface Impact: No

Prerequisite(s):

In order to reproduce this issue, you must configure a custom IEG script definition question page to run in the Citizen Workspace Application containing the following:

  1. A check-box input field.
  2. A dynamically enabled/disabled drop-down field based on the value of the check-box.
  3. A dynamically enabled/disabled input field based on the option selected in the drop-down field.

Steps to Reproduce:

  1. Launch the custom assessment script through the Citizen Workspace Application.
  2. Check the check-box to enable to the drop-down field.
  3. Select the value in the drop-down field to enable the next input field.
  4. Uncheck the check-box.
  5. Issue: The drop-down becomes dynamically disabled, but the input field does not.

Resolution:

The javascript executed to dynamically enable and disable input fields has been updated to ensure any input fields dynamically enabled by the value of a drop-down are disabled when their enabling drop-down becomes disabled.

Technical:

The JavaScript class that was updated is:

PO08868, WorkItem:264098 - Custom functions that are invoked when navigating through certain scenarios in an Intelligent Evidence Gathering Script may execute on the wrong entity leading to unexpected behavior

Issue Description:

During the completion of an IEG (Intelligence Evidence Gathering) assessment when a custom function is invoked, a member details page appears to be skipped and a ghost member appears. This occurs only after navigating backward using the left-hand sections panel from a page where you are entering additional information for a household member.

User Interface Impact:** **No

Steps to Reproduce:

  1. Login as Insurance Affordability caseworker.
  2. Register a Person and start a new application.
  3. Enter the applicant details and also make sure to enter details for one household member.
  4. On the Tax Dependent Information page for the household member click Getting Started in the sections panel.
  5. Continue back through the script until you reach the Other Household Members page.
  6. Click Next to open the Household Members Details page.
  7. Issue: The previously displayed question page for entering information about the household member is unexpectedly skipped and you are presented with a question page for entering a new household member.

Non Healthcare Reform Scenario:

Note:

If you are a customer that does not use the Healthcare Reform Solution but have configured Intelligence Gathering Scripts as an Intake mechanism, you can reproduce this scenario by performing the following prerequisite steps to configure an assessment.

Prerequisite(s):

There should be an initial section with one question page. There should then be a second section containing:

Steps to Reproduce:

  1. Launch the custom assessment script.
  2. Navigate to the final question page by entering information for the primary applicant and one household member.
  3. Navigate back to the initial section.
  4. Click Next until you reach the question page within the loop.
  5. Issue: The previously displayed question page for entering information about the household member is unexpectedly skipped and you are presented with a question page for entering a new household member.

Resolution:

The previously skipped household member question page is now displayed correctly instead of the new member question page and the assessment can be completed successfully.

Technical:

A callout is an Intelligent Evidence Gathering (IEG) script element that is used to invoke code which is not part of IEG. It can be used to execute a custom function which, for example, modifies the attributes of an entity on the Datastore.

This issue was resolved by ensuring entities are ordered correctly before each IEG callout script element is executed, preventing unexpected behavior when navigation through an IEG script.

The java class that was updated is:

Evidence Broker

PO08698, WorkItem:245582 - Verifications are not being shared when evidence is added to a target case from the incoming evidence list page

Issue Description:

As part of configuring evidence to share, an administrator has the option of determining if verifications associated with the evidence should be shared. When evidence, which has been configured to share its verifications, is shared and appears on the incoming evidence list page of a target case, adding the evidence results in the associated verification being lost.
User Interface Impact: No

Prerequisite(s):

Configure evidence sharing for any evidence type that requires a verification from Integrated Case A to Integrated Case A with Trusted Source set to No and Share Verifications set to Always.

Steps to Reproduce:

  1. Login as a caseworker.
  2. Register a Person and create two integrated cases.
  3. Navigate to the first integrated case and add the evidence that was configured for sharing.
  4. Add proof to satisfy the outstanding verification and apply changes.
  5. Navigate to the incoming evidence list page on the second integrated case.
  6. Expand the incoming evidence and select Add to Case from the actions menu.
  7. Navigate to the in-edit evidence page.
  8. Issue: The evidence added from the incoming evidence list page does not have a verification associated with it.

Resolution:

This issue has been resolved. When evidence is added to a case from the incoming evidence list page, the system will now correctly copy across the associated verification items.

PO08260, WorkItem:246460 - Add to case not correctly setting the evidence relationship between the parent and child where the parent has an optional relationship with the child

Issue Description:

There is an issue when adding dynamic evidence to a case from the incoming evidence page. Where dynamic evidence has been configured to have an optional parent and the parent must be added first, no parent-child relationship is created on the Evidence Relationship entity. This issue causes validations to be thrown when the evidence is activated.

**User Interface Impact: **No

Prerequisite(s):

  1. Configure evidence sharing between the Insurance Affordability Application and the Insurance Affordability integrated case with Trusted Source set to Yes for all evidence types except for Application Filer and Authorization Details. Trusted Source should be set to No for these two evidence types.

Steps to Reproduce:

  1. Login as an Insurance Affordability caseworker.
  2. Register a new Person.
  3. From the tab menu on the person home page, select New Application.
  4. Complete and submit the application.
  5. Open the application case.
  6. Click on the Evidence tab and select Dashboard.
  7. Add Authorization Details evidence, selecting Application Filer as the parent evidence.
  8. Delete the Application Filer Consent evidence if it exists.
  9. Authorize the application case.
  10. Open the newly created Insurance Affordability integrated case.
  11. Click on the Evidence tab and select Incoming Evidence.
    • One business object is displayed which consists of Application Filer and Authorization Details.
  12. Add both the Application Filer and Authorization Details evidence to the case using the Add To Case action.
  13. Issue: When activating the evidence from the evidence workspace, the following validation is thrown: 'A parent evidence must be specified. This can be one of Application Filer.'

Resolution:

The issue arose as there was no record created on the Evidence Relationship entity between the Application Filer (parent) and the Authorization Details (child). This was due to a defect in how relationships between optional parents and associated child evidence are managed. This has now been resolved and relationships between optional parents and child evidence are now created correctly.

WorkItem:260078 - Incoming evidence that has been shared as a deletion disappears after refreshing the page

Issue Description:

During evidence sharing with Trusted Source set to No, when evidence is deleted and shared to another case it appears on the incoming evidence list page. If the existing evidence is linked to and is identical to the incoming deleted evidence, refreshing the incoming evidence list page results in the deleted evidence disappearing from the list.
User Interface Impact: No

Prerequisite(s):

  1. Login in as an administrator.
  2. Configure identical evidence sharing for Application Filer and Application Filer Consent evidence from Insurance Affordability integrated case to Insurance Affordability integrated case. Ensure that Trusted Source is No for both.

Steps to Reproduce:

  1. Login as an Insurance Affordability caseworker.
  2. Register a new Person.
  3. Create and authorize a new application.
  4. Create a second application for the same person.
  5. Authorize the second application to create a second integrated case.
  6. Review both integrated cases for incoming evidence. If there is any on either case, select the 'Reject as not required' option.
  7. Navigate to the first integrated case and modify Application Filer and Application Filer Consent evidence by adding end dates.
  8. Apply changes.
  9. Navigate to the incoming evidence list page on the second integrated case.
  10. Choose the option 'Update with incoming' for both Application Filer and Application Filer Consent. Choose the option 'Correction' when prompted.
  11. Apply changes.
  12. Navigate back to the first integrated case and delete the Application Filer Consent evidence.
  13. Apply changes.
  14. Issue: On the second integrated case there is incoming evidence for the deleted Application Filer Consent, but when the incoming evidence list page is refreshed the evidence disappears.

Resolution:

The incoming evidence list page contains processing to set evidence to be discarded when it is identical to existing evidence on the case. This processing has been updated to allow the display of identical evidence if the incoming record is a deletion so that a user can now action that evidence.

PO08730, WorkItem:260085 - Unhandled server exception on the incoming evidence list page on expanding the incoming Absent Parent business object

Issue Description:

When an Absent Parent business object, which consists of Absent Parent, Child Support Enforcement, Absent Parent Child Support, and Absenteeism records, is shared to the incoming evidence list page of a case with an existing Absent Parent business object, an unhandled server exception is thrown when the caseworker expands the Absent Parent business object.
Specifically, the exception is thrown when the existing Absent Parent business object, which consists of the same four evidence types, Absent Parent, Child Support Enforcement, Absent Parent Child Support, and Absenteeism, has an in-edit effective-dated change on the Child Support Enforcement evidence.
**User Interface Impact: **No

Prerequisite(s):

  1. Login as an administrator.
  2. Navigate to Evidence Sharing under Rules and Evidence in the shortcuts panel.
  3. Configure Evidence Sharing with Trusted Source set to Yes between two Income Support integrated cases for the following evidence types:
    • Absent Parent
    • Absent Parent Child Support
    • Child Support Enforcement
    • Absenteeism
  4. Click Save and Exit.

Steps to Reproduce:

  1. Login as an Income Support caseworker.
  2. Register a new Person.
  3. Select New Application from the person tab.
  4. Create and submit an application case for Medical Assistance, backdated 1 year ago for the person ensuring to add a child in the script.
  5. Navigate to the newly created income support application.
  6. Navigate to the evidence dashboard add the following evidence types in the following order:
    • Absent Parent
    • Absent Parent Child Support
    • Child Support Enforcement
    • Absenteeism
  7. Apply changes.
  8. Create and submit a second application case for Medical Assistance, backdated 6 months ago for the person.
  9. Navigate to the newly created income support application.
  10. Use the Guided Change wizard to add the child from the first application as a member on the second application.
  11. Navigate to evidence dashboard add the following evidence types in the following order:
    • Absent Parent
    • Absent Parent Child Support
    • Child Support Enforcement
    • Absenteeism
  12. Apply changes.
  13. Make an effective-dated change to Child Support Enforcement on the second application but leave it in-edit.
  14. Navigate to the incoming evidence list page on the second income support application and expand the Absent Parent business object.
  15. Issue: An unhandled server exception is encountered.

Resolution:

This issue has been resolved and there is no longer an unhandled server exception experienced when performing the above scenario.

Technical:

The underlying problem here was a ConcurrentModificationException being thrown when the Absent Parent business object to be displayed was been constructed. This happened as the Absent Parent business object that was being iterated over was increased in size during this iteration process. This issue is now resolved and the unhandled server exception is no longer thrown.

PO08724, WorkItem:260086 - Unhandled server exception on incoming evidence list page after Advanced Evidence Sharing is enabled

Issue Description:

When navigating to the incoming evidence list page of an Insurance Affordability integrated case with Advanced Evidence Sharing enabled, an unhandled server exception occurs when reading address evidence that was created in resilience mode by the deprecated evidence broker. Resilience mode is a mechanism used in evidence sharing to ensure evidence is still delivered to a case via the incoming evidence list page after there were errors trying to automatically accept the evidence.

**User Interface Impact: **No

Prerequisite(s):

  1. Login as a system administrator.
  2. Navigate to Property Administration under Application Data in the shortcuts panel.
  3. Search for the property 'curam.aes.advancedEvidenceSharingEnabled' and ensure its value is set to NO so that the old evidence broker is invoked.
  4. Click Publish if the value needed to be changed.
  5. Login as an administrator.
  6. Navigate to Sections under User Interface in the shortcuts panel.
  7. Locate the section with ID ADMINAPPSection and click on it to open it.
  8. Click on the Tabs tab and use the Add page action to search for and add the tab with the name EvidenceBroker.
  9. Click on the Shortcuts Panel tab and locate the Group with ID RulesAndEvidence.
  10. Use the toggle to drill in and view the links associated with the RulesAndEvidence group.
  11. For the entry with Link ID AdvancedEvidenceSharing, use the Edit row-level action to update the Page ID to EvidenceBroker_listIdenticalSharedEvidenceConfig, making note of the Page ID that was there.
  12. Publish the changes using the Publish link under User Interface in the shortcuts panel.
  13. Navigate to Evidence Sharing under Rules and Evidence in the shortcuts panel.
  14. Use the New page action to set up the following identical sharing configuration for Address evidence, if they don't already exist, with Auto Accept and Auto Activate both selected:
    • Insurance Affordability (Application Case) to Insurance Affordability (Integrated Case)
    • Person to Insurance Affordability (Application Case)
    • Person to Insurance Affordability (Integrated Case)
    • Insurance Affordability (Integrated Case) to Person

Note:

To undo the changes above, make sure to:

  1. Remove the newly added EvidenceBroker tab added at step 8 above.
  2. Revert back to the old Page ID that was overwritten by EvidenceBroker_listIdenticalSharedEvidenceConfig at step 11 above.
  3. Publish the changes using the Publish link under User Interface in the shortcuts panel.

Steps to Reproduce:

  1. Login as an Insurance Affordability caseworker.
  2. Register a new Person.
  3. Create an Insurance Affordability application case for the Person.
  4. Authorize the Insurance Affordability application case to create the Insurance Affordability integrated case.
  5. Repeat the last two steps so that the Person has three authorized application cases and three integrated cases.
  6. Login as a system administrator.
  7. Navigate to Property Administration under Application Data in the shortcuts panel.
  8. Search for the property 'curam.aes.advancedEvidenceSharingEnabled' and update its value to YES.
  9. Click Publish.
  10. Login as an Insurance Affordability caseworker.
  11. Navigate to the incoming evidence list page of the most recently created integrated case.
  12. Issue: An unhandled server exception occurs.

Resolution:

This was caused by the logic in the incoming evidence list page not correctly handling empty list data that was created by the old evidence broker. This issue has been addressed and the incoming evidence is now displayed correctly.

WorkItem:260088 - Duplicate verification items are being added to verifications when evidence is shared as a correction or succession

Issue Description:

When verifications are configured to be shared, there is an issue where the number of verification items that are added to shared verifications increases incorrectly. This issue occurs for corrections and successions and results in the display of several duplicate verification items.

User Interface Impact: No

Prerequisite(s):

  1. Login as an administrator.
  2. Navigate to Evidence Sharing under Rules and Evidence in the shortcuts panel.
  3. Configure identical sharing with Trusted Source set to Yes and Share Verifications set to Always between Insurance Affordability integrated case and Insurance Affordability integrated case for Income evidence.

Steps to Reproduce:

  1. Login as an Insurance Affordability caseworker.
  2. Register a new Person.
  3. Create an Insurance Affordability application for the person.
  4. Authorize the application.
  5. Create a second Insurance Affordability application for the person.
  6. Authorize the second application to create a second integrated case.
  7. Navigate to the evidence dashboard of the first Insurance Affordability integrated case. Create Income evidence with the following values:
    • Type: Wages & Salaries
    • Amount: 100
    • Frequency: Yearly
    • Source: Manual
    • Start Date: 1/1/2010
  8. Add proof to the outstanding Verification to mark it as verified and apply changes.
  9. Navigate to the active evidence list on the second integrated case. Verify that the Income has shared correctly and is verified.
  10. Navigate back to the first integrated case and update the previous Income evidence to have an effective date of 1/1/2015 and an amount of 200.
  11. Add a different type of proof to the outstanding Verification to mark it as verified and apply changes.
  12. Navigate to the active evidence list on the second integrated case. Verify that the Income has shared correctly and is verified.
  13. Issue: The Verification proof has been duplicated during sharing and added multiple times to the verifications list on the target integrated case.

Resolution:

This issue was caused by how the verification items were retrieved from the source case. This issue has been fixed and now the system only shares the verification item associated with the current evidence being shared.

PO08710, WorkItem:260090 - Deleted child evidence from a source integrated case is not sharing to the target integrated case

Issue Description:

When parent-child evidence exists on an integrated case, the caseworker may decide to delete the child evidence. When this happens, and the child evidence is configured for sharing, the deleted evidence is not shared to a target case.
User Interface Impact: No

Prerequisite(s):

  1. Login as an administrator.
  2. Navigate to Evidence Sharing under Rules and Evidence in the shortcuts panel.
  3. Configure Evidence Sharing with Trusted Source set to Yes between two Insurance Affordability integrated cases for the following evidence:
    • Application Filer
    • Application Filer Consent
  4. Click Save and Exit.

Steps to Reproduce:

  1. Login as Insurance Affordability caseworker.
  2. Register a new Person.
  3. Create an application for the person, specifying that they file taxes but have no income.
  4. Authorize the application.
  5. Navigate to the newly created integrated case and activate the evidence.
  6. Repeat step 3 and create another application for the Person.
  7. Authorize this application to create a second integrated case.
  8. Navigate to the second integrated case and activate any evidence.
  9. Modify the Application Filer and Application Filer Consent evidence on the first integrated case by adding end dates.
  10. Apply changes.
  11. Navigate to the incoming evidence list page on the second integrated case.
  12. Add the incoming Application Filer and Application Filer Consent evidence from the first integrated case and apply changes.
  13. Delete the Application Filer Consent evidence on the first integrated case and apply changes.
  14. Issue: The Application Filer Consent evidence is not deleted from the second integrated case.

Resolution:

This issue has been resolved and the logic now considers canceled child records that are being actioned as part of the current apply changes operation and shares them correctly.

Technical:

The logic to create a business object to share works on a 'top-down' perspective. This means that when child evidence is deleted and activated, the evidence broker firstly retrieves the parent evidence and from there forms the business object by retrieving the children, grandchildren, etc. However, it did not consider canceled (child) records which meant that the child was never added to the business object to be considered for sharing. This is now resolved by considering canceled child records when building the business object to be shared.

PO08708, WorkItem:260091 - Error stating Tax Filing Status must be specified on apply changes although the evidence exists as active evidence

Issue Description:

When a parent-child business object is shared to a target case, where the parent object was previously shared to that same target case, only the child record is shared. This can result in a validation being thrown, as the child now exists on the target and is not linked to a parent.

An example of where this can occur is in sharing of a Tax Filing Status to Tax Relationship parent-child business object where the Tax Filing Status was already brokered to the target case. In this business scenario, the following error message will be thrown when activating evidence on the target:

'Parent evidence Tax Filing Status must be specified.'

**User Interface Impact: **No

Prerequisite(s):

  1. Ensure that sharing configurations exist for all evidence between the Insurance Affordability application and Insurance Affordability integrated case with Trusted Source set to Yes and Share Verifications set to Always.

Steps to Reproduce:

  1. Login as an Insurance Affordability caseworker.
  2. Register a Person (Adult).
  3. Create an Insurance Affordability application for the Adult and set the Adult as a tax filer.
  4. Authorize the application.
  5. Register a Person (Child).
  6. Create another Insurance Affordability application for the Adult with a few differences. Set Adult as tax filer, and add Child as a household member. Set Adult as the parent of Child and Adult is also a tax filer for Child.
  7. Authorize the application and choose to reuse the existing Insurance Affordability integrated case.
  8. Navigate to the integrated case and apply changes.
  9. Issue: Observe the validation 'Parent evidence Tax Filing Status must be specified' appears although the evidence exists in Active Evidence.

Resolution:

This was resolved by checking if the source parent has been matched to a parent on the target case with a business object resolution (BOR) action of Ignore (Link). If it has, then a relationship is created between the child and the existing (linked) parent on the target case.

In the scenario outlined here, the Tax Filing Status record that forms the Tax Filing Status to Tax Relationship business object is recommended a business object resolution (BOR) action of Ignore (Link), as it is identical to the existing active Tax Filing Status on the case. As part of this, it is linked to the existing active record. When the Tax Relationship is processed, the functionality for managing the Evidence Relationships now looks up the records matched against the ignored parent and creates the necessary parent-child relationships to those.

PO08690, WorkItem:260092 - Evidence shared using custom matching to recommend a Modify system action is not correctly sharing verifications to the target case

Issue Description:

When using custom matching in the Evidence Broker to perform a succession, verifications that are already verified are not being shared and this prevents the evidence from being auto-activated on the target case.
User Interface Impact: No

Prerequisite(s):

  1. Ensure there is no evidence sharing configured for Insurance Affordability integrated case to Insurance Affordability integrated case for Income evidence.
  2. Configure an implementation of the AESCustomDataMatching hook for income evidence to set the business object resolution (BOR) action to Modify.

Steps to Reproduce:

  1. Login as an Insurance Affordability caseworker.
  2. Register a new person.
  3. Submit an application with an application date of 1/1/2019.
  4. Authorise the application to create an integrated case.
  5. Submit a second application with a date of 6/1/2019.
  6. Authorise this application to create a second integrated case.
  7. On the first integrated case add income evidence with a start date of 1/1/2019 and an amount of 100.
  8. Verify the outstanding Income verification and apply changes.
  9. Login as an administrator and configure evidence sharing from Insurance Affordability integrated case to Insurance Affordability integrated case for Income with Trusted Source set to Yes and Share Verifications set to Always.
  10. Login as an Insurance Affordability caseworker.
  11. Add Income evidence to the second integrated case with a start date of 6/1/2019 and an amount of 600.
  12. Verify the outstanding Income verification and apply changes.
  13. Issue: Navigate to the first integrated case and the Income evidence is appearing as in-edit and verifications are not verified.

Resolution:

This issue was caused when forming the new evidence descriptor on the target case. This has been fixed and the verifications are now sharing correctly when custom matching is used.

WorkItem:260094 - Records merged from the incoming evidence list can have different start dates resulting in rule propagation errors when the evidence is activated

Issue Description:

Rules propagation expects that the timeline for an evidence business object starts by using the business start date and changes over time based on the effective date. Rules validate these dates by checking the start date is consistent across all records in the succession on the timeline. An evidence timeline that is constructed by the ‘Set as Latest of Incoming’ action from the incoming evidence list can fail this rules validation. The rules validation failure occurs when the start date of evidence on the incoming evidence timeline differs from the start date of evidence on the existing evidence timeline. The start date is not validated or updated as part of merging the two timelines together during the ‘Set as Latest of Incoming’ action. Also, when custom matching is used to perform a modify operation on the target case, a timeline can be formed with different start dates leading to the same rules validation.

User Interface Impact: No

Steps to Reproduce:

  1. Login as an Insurance Affordability caseworker.
  2. Register a Person and select New Application from the tab menu.
  3. Navigate through the application script ensuring to add income for 2000 with a start date in the past, 1/8/2019, for example.
  4. Complete the script and authorize the application.
  5. Open the integrated case and perform two successions on the income record by effective dating it, 3200 on 10/8/2019, and 3400 on 20/8/2019, for example.
  6. Apply changes.
  7. Create another application for the same person. This time add an income with a start date of today’s date of the same type with a different amount than already entered.
  8. On the new application case, navigate to the incoming evidence list page and there should be income evidence listed.
  9. Select the third record in the succession and select 'Set as Latest of Incoming'.
  10. Select the record on the next screen and click Next.
  11. Select New Version and enter an effective date of today’s date and click Next.
  12. The Edit Income modal opens and is populated with income details. Note that the start date is set to today’s date.
  13. Click Save.
  14. Issue: The record is saved and now there are rule propagation warnings in the system log/s because the start dates on the income evidence succession are different. Three records in the succession have a start date of 1/8/2019 and the current one has a start date of today's date.

Resolution:

When using the action 'Set as Latest of Incoming', where there are different start dates on the incoming and existing lists, evidence sharing now automatically sets the start date to the earliest start date between the two lists. The records from both sides will be in the same evidence succession set, all having the same start date. The informational message on the first page of the 'Set as Latest of Incoming' wizard has been updated to notify caseworkers of this behavior.

Technical:

The Succession processor has been updated to align the start dates across the timeline for any records that it processes. The Succession processor will continue to only allow successions to be created after the start date of the existing evidence timeline. This means that evidence cannot be added to a timeline using the Modify action unless it has an effective date which is later than the start date of the succession set. When using Custom Data Matching, the source record may not have an effective date. In this scenario, the Succession processor will use the start date of the source record as the effective date as long as it is after the target start date.

When merging timelines on a case, the 'Set as Latest of Incoming' logic will now find the earliest start date in the succession set and update all records to use that value. This means that the start date value entered in the modal may actually be ignored and the system will determine what start date to use. If the user has entered a start date that is earlier than all other start dates in the succession set, this one will be used instead. These records can still be changed before they are activated.

WorkItem:260096 - Unhandled server exception on the incoming evidence list page with Paid Employment / Earned Income logically equivalent configuration

Issue Description:

An unhandled server exception occurs when Income evidence on an Insurance Affordability integrated case is shared to Paid Employment & Earned Income on an Income Support integrated case, and then both of these are subsequently pulled onto a new Income Support integrated case. When the user accesses the incoming evidence list page on the second Income Support integrated case an unhandled server exception is thrown.

User Interface Impact: No

Prerequisite(s):

  1. Login as an administrator.
  2. Navigate to Evidence Sharing under Rules and Evidence in the shortcuts panel.
  3. Configure a new evidence sharing configuration with the following details:
    • Select Income Support as the source and Income Support as the target; and Integrated Case as both the source type and the target type.
    • Select the evidence types Paid Employment and Earned Income.
    • Share Verifications = Never, Trusted Source = Yes.
  4. Click Save and Exit.
  5. Configure a new evidence sharing configuration with the following details:
    • Select Insurance Affordability as the source and Income Support as the target; and Integrated Case as both the source type and the target type.
    • On the Add Logically Equivalent Evidence page of the wizard, select Income as the source evidence type and Paid Employment as the target evidence type.
    • Share Verifications = Never, Trusted Source = Yes.
    • Browse and upload the sample XML file from DeveloperWorks (HCRIncome_CGISSPaidEmployment.xml). This file maps income type of 'Wages and Salaries' only.
  6. Click Save and Exit.
  7. Configure a new evidence sharing configuration with the following details:
    • Select Insurance Affordability as the source and Income Support as the target; and Integrated Case as both the source type and the target type.
    • On the Add Logically Equivalent Evidence page of the wizard, select Income as the source evidence type and Earned Income as the target evidence type.
    • Share Verifications = Never, Trusted Source = Yes.
    • Browse and upload the sample XML file from DeveloperWorks (HCRIncome_CGISSEarnedIncome.xml). This file maps income type of 'Wages and Salaries' only.
  8. Click Save and Exit.

Steps to Reproduce:

  1. Login as an Insurance Affordability caseworker.
  2. Register a new Person.
  3. Add participant details of employment for the person.
  4. Create a new Insurance Affordability application for the person, adding two separate Incomes of type Wages and Salaries.
  5. Authorize the application.
  6. Login as an Income Support caseworker.
  7. Create a new Income Support case for the person.
  8. Navigate to the incoming evidence list page on this Income Support integrated case.
  9. Observe there are two business objects of Paid Employment and Earned Income evidence.
  10. Add one set of Paid Employment and Earned Income from the incoming evidence list to the case and set the employment type to part-time on the Paid Employment evidence.
  11. Apply changes.
  12. Navigate back to the incoming evidence list page.
  13. Use the 'Reject as Not Required' the other Paid Employment and Earned Income records.
  14. Create a new Income Support integrated case for the person.
  15. Navigate to the incoming evidence list page for this Income Support integrated case.
  16. Expand one of the incoming Paid Employment and Earned Income business objects.
  17. Issue: An unhandled server exception occurs on this page.

Resolution:

This issue has been resolved by updating the Evidence Relationship logic to ensure that a relationship cannot be created between two evidence records of the same type. This will prevent the infinite loop and the resultant unhandled server exception when the business objects are being constructed to present to the user on the incoming evidence list page.

Technical:

The underlying cause of the problem in the reported issue has to do with the sharing logic. During sharing, the sharedInstanceID on the Income record makes its way onto both the Paid Employment and Earned Income evidence descriptors on the target case.

The issue arises when a second Income Support integrated case is created. This pulls the Paid Employment / Earned Income business object from the first Income Support integrated case. However, when evidence is shared, the system needs to look up the source case to see if it's part of a parent-child relationship, and it looks up the Evidence Relationship table to achieve this. In this instance, the sharedInstanceID on the parent and child are the same. This means that when the system looks up the source case by sharedInstanceID, it will find both records. This ultimately results in an Evidence Relationship record being created between either a parent-parent or child-child. When a user clicks on the incoming evidence list page, the system tries to construct these objects to display to the user, but because a parent-parent or child-child Evidence Relationship exists, the system gets stuck in an infinite loop.
The issue has been addressed by preventing an Evidence Relationship from being created between two evidence records of the same type.

PO08478, WorkItem:260097 - Sharing successions when using custom data matching can result in two successions on the timeline with null effective dates

Issue Description:

The initial record in a timeline of evidence has a null effective date, the business start date is used to start the timeline. When processing incoming evidence into an existing timeline of evidence, the incoming initial record cannot be left with a null effective date otherwise the timeline is broken as it is not sequential. When using custom matching in evidence broker, the incoming initial record was created with a null effective date.

User Interface Impact: No

Prerequisite(s):

  1. Ensure there is no evidence sharing configured for Insurance Affordability integrated case to Insurance Affordability integrated case for Income evidence.
  2. Configure an implementation of the AESCustomDataMatching hook for income evidence to set the business object resolution (BOR) action to Modify.

Steps to Reproduce:

  1. Login as an Insurance Affordability caseworker.
  2. Register a new person.
  3. Submit an application with an application date of 1/1/2019.
  4. Authorise the application to create an integrated case.
  5. Submit a second application with a date of 6/1/2019.
  6. Authorise this application to create a second integrated case.
  7. On the first integrated case add Income evidence with a start date of 1/1/2019 and an amount of 100.
  8. Verify the outstanding Income verification and apply changes.
  9. Login as an administrator and configure evidence sharing from Insurance Affordability integrated case to Insurance Affordability integrated case for Income with Trusted Source set to Yes and Share Verifications set to Always.
  10. Login as an Insurance Affordability caseworker.
  11. Add Income evidence to the second integrated case with a start date of 6/1/2019 and an amount of 600.
  12. Verify the outstanding Income verification and apply changes.
  13. Navigate to the first integrated case.
  14. Issue: A succession for the income evidence is created but it has the same effective from date of null as the first record in the succession, which is incorrect.

Resolution:

This issue was caused when forming the new evidence descriptor on the target case. The effective date was not set correctly. This is resolved and the effective date is now set correctly. When performing custom matching, if an effective date is not set on the source record, the evidence start date is used as the effective date to prevent a succession being created with a null effective date.

PO08706, WorkItem:260440 - Endless sharing of Income evidence between Income Support and Insurance Affordability

Issue Description:

Logically equivalent Income evidence is being shared back and forth endlessly between an Insurance Affordability integrated case and an Income Support integrated case. A similar issue is being observed when sharing Benefit evidence on Income Support to Income evidence on Insurance Affordability.

User Interface Impact: No

Related Work Item(s): 260441

Prerequisite(s):

  1. Login as an administrator and navigate to Evidence Sharing under Rules and Evidence in the shortcuts panel.
  2. Configure a new evidence sharing configuration with the following details:
    • Select Income Support as the source and Insurance Affordability as the target; and Integrated Case as both the source type and the target type.
    • On the Add Logically Equivalent Evidence page of the wizard, select Earned Income as the source evidence type and Income as the target evidence type.
    • Share Verifications = Never, Trusted Source = No.
    • Browse and upload the relevant sharing XML file.
  3. Click Save and Exit.
  4. Configure a new evidence sharing configuration with the following details:
    • Select Insurance Affordability as the source and Income Support as the target; and Integrated Case as both the source type and the target type.
    • On the Add Logically Equivalent Evidence page of the wizard, select Income as the source evidence type and Paid Employment as the target evidence type.
    • Share Verifications = Never, Trusted Source = No.
    • Browse and upload the relevant sharing XML file.
  5. Click Save and Exit.
  6. Configure a new evidence sharing configuration with the following details:
    • Select Insurance Affordability as the source and Income Support as the target; and Integrated Case as both the source type and the target type.
    • On the Add Logically Equivalent Evidence page of the wizard, select Income as the source evidence type and Earned Income as the target evidence type.
    • Share Verifications = Never, Trusted Source = No.
    • Browse and upload the relevant sharing XML file.
  7. Click Save and Exit.

Steps to Reproduce:

  1. Login as an Income Support combined caseworker.
  2. Register a new Person.
  3. Click on the Participant Details tab and select Employment.
  4. Use the New page action to add a new Employment for the person, noting the name of the Employer, Midway DMV, for example.
  5. On the row-level action of the newly created employment, select New Working Hours.
  6. Fill in the mandatory details on the New Employment Working Hours modal and click Save.
  7. Click on the Care and Protection tab of the person and select Cases.
  8. Use the New page action to create an Income Support integrated case.
  9. Again, use the New page action to create an Insurance Affordability integrated case.
  10. On the Insurance Affordability integrated case, click on the Evidence tab.
  11. Use the Evidence Dashboard to add the following evidence:
    • Application Details
    • Citizen Status
    • SSN Details
    • Tax Filing Status
  12. Add Income evidence with the following details:
    • Income Type = Wages and Salaries
    • Source = Applicant
    • Amount = 2000
    • Frequency = Monthly
    • Start Date = 01/01/2018
    • Employer Name = <Same as in step 4 above, Midway DMV>
  13. Apply changes.
  14. On the Income Support integrated case, navigate to the incoming evidence list page.
  15. Add the Paid Employment and Earned Income evidence to the case using the Add To Case action.
  16. Apply changes.
  17. Issue: The Insurance Affordability integrated case has Income evidence on its incoming evidence list page as it has been re-shared from the Income Support integrated case, with Source set to Manual, although it was entered as Applicant.

Resolution:

The evidence sharing logic now honors the fact that the values of the attributes within a Set action have been set if the system attempts to share back to the evidence containing those values. The values will not be overridden by evidence being shared back from another case, as part of a modification, for example, if the values were already set during an insert. In the scenario above, once Source has been set on Income on the Insurance Affordability integrated case, the value will not be overridden by a subsequent share of Earned Income evidence from the Income Support integrated case.

The issue with the sharing of Benefit evidence on Income Support to Income evidence on Insurance Affordability was quite similar. The State attribute was being defaulted using a Set action when sharing Income evidence to Benefit evidence, which meant that the value originally set on the Benefit evidence was not being honored. This issue is also addressed as part of this fix.

PO08704, WorkItem:260441 - Endless sharing of Student evidence between Income Support and Insurance Affordability

Issue Description:

Logically equivalent Student evidence is being shared back and forth endlessly between an Insurance Affordability integrated case and an Income Support integrated case.

User Interface Impact: No

Related Work Item(s): 260440

Prerequisite(s):

  1. Login as an administrator and navigate to Evidence Sharing under Rules and Evidence in the shortcuts panel.
  2. Configure a new evidence sharing configuration with the following details:
    • Select Income Support as the source and Insurance Affordability as the target; and Integrated Case as both the source type and the target type.
    • On the Add Logically Equivalent Evidence page of the wizard, select Student as the source evidence type and Student as the target evidence type.
    • Share Verifications = Never, Trusted Source = No.
    • Browse and upload the relevant sharing XML file.
  3. Click Save and Exit.
  4. Configure a new evidence sharing configuration with the following details:
    • Select Insurance Affordability as the source and Income Support as the target; and Integrated Case as both the source type and the target type.
    • On the Add Logically Equivalent Evidence page of the wizard, select Student as the source evidence type and Student as the target evidence type.
    • Share Verifications = Never, Trusted Source = No.
    • Browse and upload the relevant sharing XML file.
  5. Click Save and Exit.

Steps to Reproduce:

  1. Login as an Income Support combined caseworker.
  2. Register a new Person.
  3. Click on the Care and Protection tab of the person and select Cases.
  4. Use the New page action to create an Income Support integrated case.
  5. Again, use the New page action to create an Insurance Affordability integrated case.
  6. On the Insurance Affordability integrated case, click on the Evidence tab.
  7. Use the Evidence Dashboard to add the following evidence:
    • Application Details
    • Citizen Status
    • SSN Details
    • Tax Filing Status
  8. Apply changes.
  9. On the Income Support integrated case, click on the Evidence tab.
  10. Use the Evidence Dashboard to add Student evidence with the following details:
    • School Type = English Language Institute
    • Highest Grade Completed = Eleventh Grade
    • Student Status = Part Time
    • Start Date 1/1/2019
    • Enter a school name and address
  11. Apply changes.
  12. On the Insurance Affordability integrated case, navigate to the incoming evidence list page.
  13. Select 'Add to Case' on the incoming Student evidence.
  14. On the New Student evidence page, click Save.
  15. Apply changes.
  16. Issue: On the Income Support integrated case, navigate to the Incoming Evidence list page. Student evidence has been shared.

Resolution:

The evidence sharing logic now honors the fact that the values of the attributes within a Set action have been set if the system attempts to share back to the evidence containing those values. The values will not be overridden by evidence being shared back from another case, as part of a modification, for example, if the values were already set during an insert.

In the scenario above, once HighestGradeCompleted has been set on Income on the Insurance Affordability integrated case, the value will not be overridden by a subsequent share of Student evidence from the Income Support integrated case.

Technical:

When the new Evidence Broker was released in Merative Social Program Management (SPM) 7.0.2.0, sample configurations were made available through the Merative DeveloperWorks channel as samples for customers to get up and running when configuring their own logically equivalent evidence. As part of addressing this Support Ticket, issues were found in the following sample configurations:

1. CGISSStudent_HCRStudent.xml
The following mapping was missing from this XML configuration file:

2. <Display> tag
The presence of the following Display tag is deemed unnecessary and our advice is to remove this, as its presence ensures shared evidence will appear on the incoming list if the values on the target case are different from the default values specified in the XML.

For customers reusing these configurations, making the above updates is strongly advised to prevent evidence from being shared back and forth between Income Support and Insurance Affordability.

PO08823, WorkItem:261197 - Incoming evidence that has been shared as a deletion disappears after refreshing the incoming evidence page

Issue Description:

An administrator can configure evidence to have a parent-child relationship with other evidence. Incoming evidence that is a child of a parent, and which has been shared as a deletion, disappears after refreshing the incoming evidence list page.

An example of where this can occur is in the sharing of an Income to Employer-Sponsored Coverage parent-child business object. When the child Employer-Sponsored Coverage is shared as a deletion, it disappears from the incoming evidence list page once the page is refreshed.

User Interface Impact: No

Prerequisite(s):

  1. Login as an administrator.
  2. Select Evidence Sharing under Rules and Evidence in the shortcuts panel.
  3. Use the New Sharing Configurations page action to configure Insurance Affordability (IC) to Insurance Affordability (IC) sharing.
  4. Ensure Income and Employer-Sponsored Coverage have Trusted Source set to No.

Steps to Reproduce:

  1. Login as an Income Affordability caseworker.
  2. Register a new Person.
  3. Submit an Insurance Affordability application on the current date with an income of type Wages & Salaries for $100, yearly from the current date.
  4. Authorize the application to create an Insurance Affordability integrated case.
  5. Submit a second Insurance Affordability application on the current date with an income of type Wages & Salaries for $100, yearly from the current date.
  6. Authorize the second application, choosing to create a new integrated case on the authorization modal.
  7. Confirm no evidence is appearing on the incoming evidence list page on the second integrated case.
  8. On the first integrated case add Employer-Sponsored Coverage evidence and apply changes.
  9. On the second integrated case, confirm that a combined Income and Employer-Sponsored Coverage parent-child business object is present.
  10. For the Employer-Sponsored Coverage, select Add to Case and apply changes.
  11. On the first integrated case, delete the Employer-Sponsored Coverage evidence and apply changes.
  12. On the second integrated case an incoming evidence record is initially displayed, but with only the Income evidence and no Employer-Sponsored Coverage.
  13. Issue: Refresh the incoming evidence list page and the incoming record disappears.

Resolution:

There was an issue finding the relationship between the parent Income evidence and the deleted child Employer-Sponsored Coverage evidence that caused the child evidence to be lost on the incoming evidence list. Only the parent was displayed and, since the parent is unchanged, it caused the record to be removed after the page was refreshed. The relationship is now found between the parent and the deleted child evidence, and the records display correctly on the incoming evidence list page and no longer disappear after refreshing the page.

PO08758, WorkItem:265677 - Documentation Evidence Broker guide missing details on evidence sharing triggers

Issue Description:

The Evidence Broker section 'Evidence sharing triggers' in the documentation describes how adding a case member to a case triggers the evidence broker to share evidence to that case. This description is incomplete in terms of its explanation of one instance when this trigger point will not result in evidence being shared.

User Interface Impact: No
Steps to Reproduce:
N/A

Resolution:

The documentation text has been updated to include additional information in the 'Adding a case member' section to better clarify that the adding a case member trigger point will not share evidence if the case member is added during the application authorization process because the application authorization process itself handles the evidence sharing.
https://curam-spm-devops.github.io/wh-support-docs/spm/pdf-documentation.

Financial Management

PO08721, WorkItem:259578 - Incorrect processing of manual payments for open-ended cases

Issue Description:

CREOLE based products can be configured to be open-ended. A product delivery will be open-ended if the underlying product is configured to be open-ended and certification is not required. Open-ended means that the decisions and related financial component(s) have a blank end date. Such cases will pay indefinitely until such time as the caseworker specifies an expected end date on the case. Once that happens, the old financial components are expired and new ones are generated. The new financial components will not be open-ended and will reflect the expected end date of the case.
It was found that capturing a manual payment for a period where the due financial component(s) are open-ended results in those financial components not being picked up. This means that the entire manual payment is captured as a manual payment overpayment.

User Interface Impact: No
Prerequisite(s):

  1. A CREOLE product exists on the system that is configured to be open-ended.
    • Whether a product is open-ended or not is governed by a setting on the CREOLEProduct entity, allowOpenEndCases.
  2. The product rules do not require certification to be specified for eligibility.

Steps to Reproduce (Generic):

Setting up the case

  1. Login as a caseworker.
  2. Register a new Person.
  3. Create an instance of the product configured above, paying 'Weekly By Cash In Advance On A Monday'.
  4. Add the necessary evidence to make the product delivery eligible.
  5. Submit, approve, and activate the case.
  6. Click on the Financials tab and select Transactions.
  7. Generate the first payment on the case using the Issue Payment page action.
  8. Now select the Simulate Payment page action.
  9. Specify the Payment Due Date for the next payment and click Simulate. Make sure to keep a note of the amount due.

Capturing the manual payment

  1. Login as a financial user.
  2. Click on the Transaction and Accounts workspace tab.
  3. Expand the shortcuts panel and select Record a Manually Issued Payment.
  4. Search for the person and select them in the Search Results.
  5. On the second page of the wizard select the product delivery case.
  6. On the third page select the case nominee.
  7. On the last page of the wizard specify the manual payment details, including:
    • The cover period of the next payment due.
    • The amount of the payment - this should be the same as the amount from the Simulate Payment step above.
  8. Click Save.

Checking the manual payment

  1. Login as a caseworker.
  2. Use the Person Search to find the person registered above.
  3. From the person home page, click on the Care and Protection tab.
  4. Click on the product delivery case.
  5. Click on the Financials tab and select Transactions.
  6. Issue: The manual payment line item that was captured shows up as a Manual Payment Overpayment instead of the component that was due, as per the Simulate Payment step above.

Resolution:

This issue is now resolved and the manual payment processing works as expected. In the scenario above, the line item for the manual payment will reflect what was displayed as part of the Simulate Payment process.

Technical:

The underlying problem was that the manual payment processing did not handle open-ended financial components, that is, financial components with null end dates. The processing has been updated to handle financial components with null end dates.

PO08811, WorkItem:261613 - Incorrect payment method is assigned to a second manual payment on a product delivery case when a Manual Payment Overpayment is generated

Issue Description:

****When a manual payment is captured and the entire amount becomes a Manual Payment Overpayment, the delivery method type on the Manual Payment Overpayment line item is incorrect and different from the delivery method type on the associated Payment Instruction and Payment Instrument. The delivery method display on the manual payment list of the Financial Transactions of a product delivery case is not consistent with what was specified when recording a manually issued payment.
User Interface Impact: No

Steps to Reproduce (Generic):

  1. Login as a superuser.
  2. Register a new Person and create a new integrated case.
  3. Add a new product delivery to the integrated case and select any weekly in advance on a Monday delivery pattern, such as Weekly by Cheque in Advance on a Monday, for example.
  4. Add the necessary evidence to the integrated case that will ensure one component is payable on the product delivery.
  5. Activate the evidence.
  6. On the product delivery, click on the Financials tab and select Certifications.
  7. If a certification has not been added automatically, use the New page action to add one with the following details:
    • From Date = Todays date.
    • To Date = Any Sunday in the future.
  8. Submit the case for approval.
  9. Activate the case.
  10. Click on the Financials tab and select the Simulate Payment page action.
  11. Specify the Payment Due Date as the certification from date entered above and click Simulate.
  12. Make a note of the Cover Period and Amount.
  13. Click Close.
  14. Login as a financial user.
  15. Select Record a Manually Issued Payment from the shortcuts panel.
  16. In the Record Manually Issued Payment wizard, search for and select the client and click Next.
  17. Select the product delivery created above and click Next.
  18. Select the nominee and click Next.
  19. On the final page of the wizard, provide the following manual payment details:
    • Amount = Amount noted from the Simulated Payment above.
    • Cover Period From = Todays date.
    • Cover Period To = Next Sunday.
    • Payment Date = Todays date.
    • Delivery Method = Cash.
  20. Click Save.
  21. Login as a superuser and search for the product delivery.
  22. Click on the Financials tab and select Transactions.
  23. Verify everything looks correct for the Manual Payment previously created.
  24. Login as a financial user.
  25. Capture another manual payment for the same period as entered before with an amount of $10 and a delivery method of Cash.
  26. Login as a superuser and search for the product delivery.
  27. Click on the Financials tab and select Transactions.
  28. Use the toggle to drill into the details of the second manual payment.
  29. Issue: The delivery method displayed on the Financial Transactions list for the second manual payment is incorrect and different from that displayed on the delivery details of the manual payment method.

Resolution:

This issue has been resolved and the delivery method shown on the manual payment list of the Financial Transactions of a product delivery case is now consistent with what was specified when recording a manually issued payment, as well as what's on the associated Payment Instruction and Payment Instrument.

PO08802, WorkItem:261669 - Capturing a manual payment expires a financial component resulting in it not being available for future payment processing

Issue Description:

When capturing a manual payment, a financial component that should not be processed can be closed (expired) prematurely. This results in that financial component not being available for processing, either online or by the financials batch processes.

**User Interface Impact: **No

Steps to Reproduce (Generic):

  1. Login as a superuser.
  2. Register a new Person.
  3. Add a new integrated case for the person.
  4. Add the necessary evidence that will ensure two components are payable.
  5. Add a new product delivery to the integrated case, payable weekly in advance on a Monday.
  6. Add a certification to the product delivery case with the following details:
    • From Date = Today
    • To Date = Some date in the future
  7. Submit, approve, and activate the case.
  8. Click on the Financials tab and select the Simulate Payment page action.
  9. Specify the Payment Due Date as the certification from date entered above and click Simulate.
  10. Make a note of the Components, Cover Period, and Amount.
  11. Login as a financial user.
  12. Select Record a Manually Issued Payment from the shortcuts panel.
  13. In the Record Manually Issued Payment wizard, search for and select the client and click Next.
  14. Select the product delivery created above and click Next.
  15. Select the nominee and click Next.
  16. On the final page of the wizard, provide the following manual payment details:
    • Amount = Full amount for the first component in the Simulated Payment above.
    • Cover Period From = Today
    • Cover Period To = Sunday of the current week
    • Payment Date = Today
    • Delivery Method = Cash
  17. Click Save.
  18. Login as a superuser.
  19. On the product delivery, click on the Financials tab and select the Issue Payment page action.
  20. Click Yes on the Issue Payment confirmation modal.
  21. Issue: A validation is returned to the user 'There is no payment due on this case today.' The financial component for the second payable component is incorrectly closed during the capturing of the manual payment. It should remain open (live) and available for processing.

Resolution:

This issue has been resolved and now in the above scenario, the financial component will not be closed prematurely and will be available for processing either online or by the financials batch processes.

Solutions

Income Support
Child Welfare
Child Welfare SDM

PO08571, WorkItem:254180 - Apply Evidence to Other Case Participants cluster is not being displayed after a member is added using the Guided Change wizard

Issue Description:

A multi-participant evidence update is a configuration in dynamic evidence that allows an update to a specific instance of an evidence type for a case participant to be applied to other case participants on the same case. The other case participants appear in a cluster where a user can select those they want the change to apply to.
On an Insurance Affordability integrated case, when a caseworker edits evidence on which the multiple participant evidence update is available, members added via guided change are not displayed in the multi-participant cluster. This is happening because the end date for evidence created via guided change is stored differently to evidence created manually, and the multi-participant cluster is only displaying members who have been added manually.

**User Interface Impact: **No

Steps to Reproduce:

  1. Login as an Insurance Affordability caseworker.
  2. Register a new Person (P1).
  3. Register a new Person (P2).
  4. From the tab action menu of P1's home page select New Application Form.
  5. Complete and submit the application ensuring that an Address and a Social Security Number are specified.
  6. Navigate to the newly created Application Case.
  7. Add all verification items required by the application evidence.
  8. Authorize the application case.
  9. Navigate to the integrated case created by authorizing the application case.
  10. From the Guided Change menu item of the tab action menu select Add a Member.
  11. Complete the Guided Change wizard to add P2 to the integrated case stating that they live with P1.
  12. On the Guided Change list page, select the row-level action Mark Complete to complete the process.
  13. Activate all evidence created by the Guided Change wizard.
  14. Navigate to the Addresses evidence type.
  15. Edit the Private Address for P2.
  16. Observe that P1's Private Address is listed in the cluster entitled Apply Evidence to Other Case Participants.
  17. Cancel the edit.
  18. Edit the Private Address for P1.
  19. Issue: There is no cluster entitled Apply Evidence to Other Case Participants displayed.

Resolution:

This issue is now resolved and members added via guided change to the case are now included in the Apply Evidence to Other Case Participants cluster.

Technical:

This issue was resolved by changing the SQL in the mechanism that performs a search for multi-participant evidence, in such a way that it finds records that have an end date of 00010101, as well as the regular null end date.

PO08603, WorkItem:254715 - Estimated From and To Ages are not displaying on the Participant home page

Issue Description:

When a participant is added to an intake and an age range is provided rather than a date of birth, the participant list is incorrectly displayed with Age Not Recorded rather than with the estimated age. The estimated age is also not displayed correctly on the prospect person's home page.

User Interface Impact: No

Steps to Reproduce:

  1. Login as a Child Welfare intake worker.
  2. Create a new Child Protection Services intake.
  3. Click on the Participants tab and select New Participant from the page action menu.
  4. Enter the First Name, select any Role, and enter Age Range (2 - 9).
  5. Click Next and click Finish.
  6. Issue 1: On the Participants list, notice the participant link contains Age Not Recorded.
  7. Click the participant link to open the prospect person home tab content page.
  8. Issue 2: On the context panel, Age Not Recorded is displayed instead of Estimated Age, 2-9.
  9. Issue 3: On the home tab content page, the Estimated From Age and Estimated To Age fields are blank.

Resolution:

The issues are now resolved and correct age details are displayed on the participants' list on the intake and the prospect person's context panel and the home tab content page.

PO08895, WorkItem:263571 - The Gender field does not completely display the value from the drop-down list in the Person Search modal window used in Income Support

Issue Description:

As part of adding a member to an Insurance Affordability integrated case, when a user selects to search for a participant, the Gender drop-down field does not completely display the values on the Person Search modal window.

User Interface Impact: No

Steps to Reproduce:

  1. Login as an Insurance Affordability caseworker.
  2. Register a new Person.
  3. From the tab action menu of the person home page, select New Application.
  4. Complete and submit the intake application.
  5. Navigate to the application case and verify any outstanding verifications.
  6. Authorize the application.
  7. Navigate to the integrated case created.
  8. Select Add a Member from Guided Change menu item on the tab action menu.
  9. Under Participant Details section of the Add Member wizard, use the search field to search for a participant.
  10. Select Female in the Gender drop-down field of the Person Search modal window.
  11. Issue: The Gender field value is not completely displayed in the drop-down.

Resolution:

This issue is now resolved and the Gender drop-down values are displayed in full on the Person Search modal window.
Income Support

Medical Assistance

PO08660, WorkItem:255752 - When applying changes, a not selected unverified evidence is preventing a selected verified evidence from being applied to case

Issue Description:

Apply changes are incorrectly prevented when there is an outstanding verification on in-edit evidence that is not selected on the Apply Changes modal. This issue occurs when the evidence that is selected impacts household composition and at least one authorized unit exists for either Food Assistance, Cash Assistance, or Medical Assistance.

User Interface Impact: No

Steps to Reproduce:

  1. Login as an Income Support caseworker.
  2. Register a Person.
  3. Create a Medical Assistance application for that Person.
  4. Submit and authorize the application.
  5. On the Integrated Case edit the Household Member evidence.
  6. Add proof to verify the outstanding verification.
  7. Add Benefit evidence.
  8. Confirm the Benefit evidence results in an outstanding verification.
  9. From the Evidence tab actions menu select Apply Changes.
  10. Apply the changes only to Household Member evidence.
  11. Issue: The change cannot be applied due to the outstanding verification on the Benefit evidence, even though this evidence is not selected for apply changes.

Resolution:

This issue is now resolved. When changes are applied to evidence that affects the household composition, checks for outstanding verifications are only applied to the evidence selected.

Technical:

As a part of the fix, the call to the redundant methods was removed and the redundant methods were marked as deprecated in the codebase.

In EJBServer/components/ISProduct/source/curam/isproduct/sl/impl/ChangeOfCircumstance.java the following method call was removed:

and the following two methods were deprecated:

WorkItem:256369 - Year and Year Range code tables only have entries available for selection up to the year 2020

Issue Description:

Some Income Support evidence types contain attributes for selection of a calendar year. Year and Year Range code tables, as used in Exemption, Extension, and Countable Assistance History evidence, only have entries up to 2020 when creating and modifying those evidence types. Users will not be able to select the appropriate year after 2020.
User Interface Impact: No
Steps to Reproduce:

  1. Login as a System Administrator.
  2. Navigate to Code Tables under Application Data in the shortcuts panel.
  3. Enter 'year' into the Search field and click the Search button.
  4. Issue: The Year and Year Range code tables only have entries up to 2020.
  5. Login as an Eligibility Worker.
  6. Submit an Income Support application.
  7. Navigate to the Evidence tab of the application.
  8. Attempt to add new Exemption or Extension evidence.
  9. Issue: The maximum year value available for selection from the Year drop-downs on both New Exemption Evidence and New Extension Evidence modal screens is 2020.

Resolution:

This issue is now resolved. Additional values were added to the relevant code tables so the range available for selection is from 2010 to 2030.

Technical:

The values in the Year and Year Range code tables are available from 2001 and 2002, respectively. The values from 2001-2009 in the Year code table and 2002-2010 in the Year Range code table are now deactivated. If required, these can be reactivated by reverting the status from DISABLED to ENABLED.

WorkItem:262741 - New hook point to support cascading eligibility between non-MAGI and MAGI programs

Issue Description:

A new hook point has been introduced to allow for custom persistence of eligibility data on new and changed Income Support decisions to support cascading eligibility between Income Support and Insurance Affordability; ISMedicaidEligibility evidence is no longer created by the system.
See attached guide - Guide_Cascade_NonMagiToMagi.pdf for details of the new hook point and guidance on implementing cascading eligibility.

MEDICAL ASSISTANCE

PO08891, WorkItem:248466 - Long Term Care Period of Ineligibility (POI) calculated incorrectly for second eligibility check on the same day

Issue Description:

Long Term Care Period of Ineligibility (POI) records are not created or modified correctly on Check Eligibility if a Check Eligibility action has already been performed on the same day. This may result in incorrect determinations because the system will still use the original Period of Ineligibility record.

**User Interface Impact: **No

Steps to Reproduce:

  1. Login as an Income Support caseworker.
  2. Register a new person over 65 years of age and submit a Medical Assistance application.
  3. On the application, add Medical Institution and Level of Care evidence.
  4. Add Resource Transfer evidence with the following details:
    • Resource: Liquid resource
    • Item type: Cash on hand
    • Fair market value: 5,000
    • Uncompensated value: 5,000
  5. Clear all verifications and apply changes.
  6. Check Eligibility for Medical Assistance.
  7. Open the Ineligibility Period tab, a new Ineligibility period is created.
  8. Edit the Resource Transfer evidence, changing Fair market value, and Uncompensated value each to 10,000 and apply changes.
  9. Perform Check Eligibility action for Medical Assistance.
  10. Issue: There is no change to the Period of Ineligibility.

Resolution:

The logic within the Long Term Care rules that prevented re-calculation of the Period of Ineligibility if one had already been determined on the same day, has been corrected. Now, when Check Eligibility is executed, an existing Period of Ineligibility will be modified, or a new one created, if applicable.

Technical

The following rules have been modified to address this defect:

PO08879, WorkItem:263287 - Sanction Recommendations created incorrectly for Medical Assistance products other than Long Term Care

Issue Description:

Sanction recommendations are being created for all Medical Assistance programs in Income Support when they should apply to the Long Term Care program alone.

User Interface Impact: No

Steps to Reproduce:

  1. Login as an Income Support eligibility worker and submit a Medical Assistance application to be eligible for QMB (Qualified Medicare Beneficiary).
  2. Authorise the application and activate the product delivery.
  3. On the integrated case, add Resource Transfer evidence with the following details:
    • Resource: Liquid resource
    • Item type: Cash on hand
    • Fair market value: 5,000
    • Uncompensated value: 5,000
  4. Apply changes.
  5. Issue: A sanction recommendation is created.

Resolution:

The Long Term Care Sanction Assessment was previously being run for all Medical Assistance products resulting in incorrect sanction recommendations. This is now restricted to Long Term Care, Medically Need Long Term Care, and Medically Needy Long Term Care with Spend Down programs.

PO08881, WorkItem:263313 - Long Term Care Period of Ineligibility (POI) incorrectly uses the system date when determining the look-back period resulting in incorrect LTC decisions

Issue Description:

On a medical assistance application, a person can be deemed ineligible for long-term care benefit if they made an invalid resource transfer within the 60 months time period preceding the date when they are institutionalized or when they apply for Medicaid, whichever is the later. This 60 months period is called the look-back period.

The current system date is being used to calculate the look-back period instead of the later of the date the person is institutionalized and applies for Medicaid, resulting in incorrect LTC decisions.

User Interface Impact: No

Prerequisite(s):

  1. Set the system date to 7/28/2020.

Steps to Reproduce:

  1. Login as an Income Support eligibility worker.
  2. Register a new person over 65 years of age and submit a Medical Assistance application on 1/1/2020, with Level of Care and date entered Medical Institution on that date.
  3. Add Resource Transfer evidence with a transfer date of 6/1/2015:
    • Resource: Liquid resource
    • Item type: Cash on hand
    • Fair market value: 5,000
    • Uncompensated value: 5,000
  4. Clear all verifications and apply evidence changes.
  5. Check Eligibility for Medical Assistance.
  6. Issue: No Period of Ineligibility record is created when there should have been one starting 1/1/2020 to 1/31/2020.

Resolution:

The look-back period calculation has been corrected to use the later of the application filing date and date entered in the medical institution when determining the look-back period, and not the current system date.

Technical

The following rules have been modified:

PO08884, WorkItem:263315 - New Period of Ineligibility (POI) record created on check eligibility when the original record has been manually modified

Issue Description:

The Income Support applications allow a user to modify the Period of Ineligibility (POI) that is generated by the system when a check eligibility action is performed. A second Long Term Care Period of Ineligibility record is created incorrectly on check eligibility if the original record has been manually modified.

User Interface Impact: No

Steps to Reproduce:

  1. Login as an Income Support eligibility worker.
  2. Register a new person over 65 years of age and submit a Medical Assistance application.
  3. On the application add Medical Institution evidence and Level of Care evidence.
  4. On the application, also add Resource Transfer evidence:
    • Resource: Liquid resource
    • Item type: Cash on hand
    • Fair market value: 5,000
    • Uncompensated value: 5,000
  5. Clear all verifications and apply changes.
  6. Check Eligibility for Medical Assistance.
  7. Open the Ineligibility Period tab and note that a new Ineligibility period is created.
  8. Edit the Period of Ineligibility changing the end date.
  9. Check Eligibility for Medical Assistance again.
  10. Issue: A new Period of Ineligibility record is created.

Resolution:

This has been resolved, a new Period of Ineligibility record is not created when another exists for the citizen covering any overlapping dates, instead, the existing record is modified.

Technical:

On the modification of the Period of Ineligibility record, the poiDeterminationDateOpt field was not being maintained. This field is used by the Period of Ineligibility logic when determining whether to create a new Period of Ineligibility or modify an existing one. This field is now being passed from the UIM to the Facade so that it is retained on the modify action.

The following UIM has been modified:

PO08892, WorkItem:263444 - Sanction recommendation being created redundantly for Medical Assistance

Issue Description:

On a Medical Assistance application, a sanction recommendation is incorrectly created when a sanction already exists for the same period. The system does not take into account the sanctionable period of the previous recommendation.

User Interface Impact: No

Steps to Reproduce:

  1. Login as an Income Support eligibility worker.
  2. Register a new person over 65 years of age and submit a Medical Assistance application to be eligible for Long Term Care.
  3. Clear verifications, apply changes, and authorize the application.
  4. Activate the Long Term Care product delivery case.
  5. On the Medical Assistance integrated case, add a Resource Transfer evidence:
    • Resource: Liquid resource
    • Item type: Cash on hand
    • Fair market value: 5,000
    • Uncompensated value: 5,000
  6. Clear all verifications and apply changes.
  7. Navigate to Sanction Recommendation on the Compliance tab and create a Sanction from the newly created sanction recommendation.
  8. Make a further evidence change that does not impact the sanctionable period and apply evidence changes.
  9. Issue: A new sanction recommendation is created in addition to the one previously created.

Resolution:

The rules have been modified so that when new a sanction recommendation is calculated, periods that overlap an existing sanction will be excluded.

Technical

The following rules have been modified:

WorkItem:265223 - Open Enrollment Period configuration not available for the year 2021

Issue Description:

No open enrollment period configuration for 2021 for Insurance Affordability is available.

User Interface Impact: No
Steps to Reproduce:

  1. Login as an administrator.
  2. Navigate to Open Enrollment Period under Health Care Reform in the shortcuts panel.
  3. Issue: No open enrollment period for 2021 is configured.

Resolution:

A new open enrollment period configuration is now available. The configuration is: Start Date 11/1/2020, End Date 12/15/2020, Coverage Start Date 1/1/2021, and Coverage End Date 12/31/2021.

Child Welfare

PO08607, WorkItem:254711 - The New Participant modal page hangs when selecting cancel on the primary client alert message dialog

Issue Description:

When adding a primary participant to a Child Welfare intake or investigation, an alert dialog pops up if there is already an existing primary participant on the case. Upon selecting Cancel on the dialog, the modal screen hangs and the only way to stop it is to close the modal window.
**User Interface Impact: **No

Steps to Reproduce:

  1. Login as a Child Welfare intake worker.
  2. Select New Intake under Intakes in the shortcuts panel.
  3. Set the Category to Child Protection Services and type to Child Abuse or Neglect and click Save.
  4. Click on the Participants tab and select the New Participant page action.
  5. Add participant details and ensure to select the Primary Client check-box on the first page before clicking Next.
  6. On the Potential Matches page, click Finish.
  7. Create a second participant from the New Participant page action menu.
  8. Again, add the participant details and select the Primary Client check-box.
  9. Click Next.
  10. An alert dialog pops up with the message: 'A 'Primary Client' already exists for the case. Do you want to change the 'Primary Client' to this participant?'.
  11. Click Cancel.
  12. Issue: The dialog is dismissed but the New Participant modal hangs and cannot be interacted with.

Resolution:

When a user now receives an alert that there is already an existing primary participant on the case, it is now possible to cancel the action and return to the process of creating the new participant.
Technical:

The Javascript function called by the validation dialog has been fixed to prevent the form being submitted when Cancel is selected.

PO08595, WorkItem:254718 - Discharge narrative continues to be displayed after removing the discharge date

Issue Description:

When a removal is created for a child in Child Welfare and the child is subsequently returned home, the removal is ended by the use of the discharge functionality. Discharging the child requires the user to provide a discharge date and a narrative text. If the discharge date is subsequently removed, the narrative provided as part of the discharge is still visible to the user.

**User Interface Impact: **No

Steps to Reproduce:

  1. Login as a Child Welfare caseworker.
  2. Register a child and create a new Ongoing Case.
  3. From the Ongoing Case home page, click on the Removals and Placements tab.
  4. Select New Removal from the page action menu.
  5. Populate the required fields and ensure the Date is in the past.
  6. Click Save and Place.
  7. Provide the details for the Placement, select the Provider, and click Finish.
  8. From the newly created Removal, select Discharge from the row-level menu.
  9. Populate the Discharge details and provide a narrative.
  10. Click Save.
  11. Use the toggle to drill down into the details of the removal.
  12. The Discharge Narrative cluster in the inline page contains the narrative provided above.
  13. From the row-level menu, select Remove Discharge Date and confirm.
  14. Again, use the toggle to drill down into the details of the removal.
  15. Issue: The Discharge Narrative cluster in the inline page still contains the narrative text.

Resolution:

This issue has been resolved. Now when a discharge date is removed, the associated narrative is no longer visible to the user.

PO08618, WorkItem:255131 - Reunification Assessment answers do not provide Caregiver Names

Issue Description:

In Child Welfare, when completing a Reunification Assessment, responses to questions can be provided for the entire family or individual family members. Where questions are specific to individual family members, the answers display as having been provided for the family rather than the individual family members.

User Interface Impact: No

Steps to Reproduce:

  1. Login as a Structured Decision Making Child Welfare caseworker.
  2. Register 3 new Persons, 2 parents, and a child.
  3. On the child's Person record, add Relationships to the parents.
  4. Create an Ongoing Case for the child.
  5. Click on the Participants tab and select the Add Related Family page action.
  6. Select the two parents and click Save.
  7. Click on the Removals and Placements tab and select New Removal.
  8. Select the child, provide any reason, and select Voluntary as the Type and Voluntary Surrender as the Sub-Type.
  9. Click Save and Place.
  10. Select Foster Care as the Type and click Next.
  11. Search for a provider, choose the provider and click Finish.
  12. Click on the Outcome Plans tab and select the New page action.
  13. Add a new Child Welfare Outcome Plan and add all 3 members.
  14. On the Outcome Plan click on the Reviews tab.
  15. Use the New page action to add a review, specifying today's date for each of the dates.
  16. Click on the Review Period hyperlink of the newly created review to open the Plan Review tab.
  17. From the Plan Review click on the Assessments tab and select a Reunification assessment.
  18. For the mom select the role of primary caregiver, for the dad select the role of secondary caregiver, and for the child select Child.
  19. On the Assessment, for all the questions except R3, select low, no, or none.
  20. For R3 for the mom, select 'Successfully completed all services recommended or actively participating...'
  21. For R3 for the dad, select 'Has participated but is not meeting objectives...'.
  22. Complete the assessment.
  23. Select the Reunification Assessment hyperlink to view the completed assessment.
  24. Click on the Answers tab.
  25. Issue: Even though the responses provided for the R3 question were specific to the mom and dad, when viewing the answers the responses display as having been provided for the family rather than for the individual family members.

Resolution:

The parents' names are displayed to differentiate the answers to the assessment questions specific to each participant.

Technical:

Updated the assessment implementation to allow for the datastore detail that contains the answers to an assessment instance with the entity name 'Caregiver' to set the associated name to the specific person who answered the particular question within the assessment questionnaire.

Child Welfare SDM

PO08573, WorkItem:254152 - In Child Welfare the Citizen Content Viewer (CCV) icons on the context panel of an investigation case are not visible when high contrast mode is enabled on a Windows operating system

Issue Description:

In Merative Social Program Management (SPM) Child Welfare module, when creating an investigation case, the Citizen Context Viewer (CCV) icons on the context panel are not visible when high contrast mode is enabled on a Windows operating system. This behavior is appearing in both the photo and list views.
User Interface Impact: No

Steps to Reproduce:

  1. Enable high contrast mode on a Windows operating system.
  2. Login as a Child Welfare Structured Decision-Making intake worker.
  3. Create an intake and add 3 participants, 2 as an Adult and 1 as an Alleged Victim.
  4. Select the Open Intake tab menu option to open the intake case.
  5. Use the New Assessment tab menu option to create an assessment.
  6. Select No or None as the answer to all questions except one.
  7. Click on the Allegations tab and select New to create a New Allegation.
  8. Select the Alleged Victim, the Unknown Maltreater check-box, the Type, and click Save.
  9. Click on the Recommendation tab and use the Assess row-level action to assess the allegation from the Response Priority cluster.
  10. Select Submit from the page action menu to submit the recommendation.
  11. Click on the Administration tab and select Tasks.
  12. Open the newly created task by clicking on the Task ID hyperlink.
  13. Click on the Make Decision link and Approve the recommendation.
  14. Click on the Intake Home link in the Supporting Information cluster to navigate back to the intake.
  15. Click on the Administration tab and select Tasks
  16. Click on the task to start an investigation.
  17. Click on the Create Investigation primary action.
  18. Select the 3 persons and click on start.
  19. Click the icons for photo and list views to alternate between both views.
  20. Issue: The CCV links are not visible in either view for the participants.

Resolution:

When high contrast mode is enabled on a Windows operating system, the user is now able to view the Citizen Context Viewer (CCV) icons on the context panel.

Technical:

This issue was resolved by updating the Java and CSS code for the CCV icons. The image for the icons is now specified directly in the HTML of the page, rather than through CSS.

The Java and CSS files that were updated are as follows:

PO08612, WorkItem:255056 - Recommendation following override is incorrect in Reunification Assessment when navigate back and forth

Issue Description:

When a user is completing the Sturctured Decision Making (SDM) Reunification Assessment (RUA) and reaches the 'recommendation' section, they are provided with the ability to override the recommendation. If the user selects a discretionary override to change the recommendation to reunify the user must then complete additional safety questions and is then returned to the 'recommendation' section. If the user then navigates back to the safety assessment questions, makes no updates to the questions, and then navigates to the 'recommendation' section again, the recommendation that was initially captured is incorrectly being updated.

User Interface Impact: No

Steps to Reproduce:

  1. Login as a Child Welfare Structured Decision-Making caseworker.
  2. Register a mother and two children.
  3. For one of the children add parent and sibling Relationships evidence.
  4. Create an Ongoing Case for the same child.
  5. Click on the Participants tab and select Case Member.
  6. Use the Add Related Family page action and add both family members to the case.
  7. Click on the Outcome Plans tab and use the New page action to create a Child Welfare Outcome Plan (not basic version), selecting all three family members.
  8. On the Outcome Plan click the Reviews tab and use the New page action to create a new review.
  9. Click on the Review Period link to open the Review in a new tab.
  10. Click on the Assessments tab and select the New page action.
  11. Select Reunification Assessment on the New Assessment page and click Next.
  12. Select each of the family members and choose the Child role for both the children and Primary Caregiver role for the mother. Click Next to start the Reunification Assessment.
  13. On Risk section, score the risk items for the household by selecting R1 as High and R2 as No and click Next.
  14. On the next page, for R3. Progress toward Case Plan Goal, select that mother has 'Successfully completed all services recommended..' option and click Next.
  15. On the next page, for Override, select No Override and click Next.
  16. On Visitation section, as no visitation plans are found and no visitation logs click Next for both the children.
  17. On the next page, for Override, select No Override for both the children and click Next.
  18. On the Recommendation section, for both the children, override the recommendation by selecting Discretionary Override and change it to Reunify. Providing an Override Reason and clicking Next navigates the user to the additional safety questions.
  19. For Factors Influencing Child Vulnerability, only select Age 0-5.
  20. For Safety Threats, select No for the first question and select Yes for all the remaining questions. Enter comments and click Next.
  21. For Safety Threat Resolution, enter the resolution comments and click Next.
  22. For Safety Intervention, select No for all the questions 1-9 and select Yes for question 10 and click Next.
  23. For Recommendation notice that Initial Recommendation as 'Reunify' and Recommendation after Safety Assessment as 'Maintain in out of home care', click Back.
  24. For Safety Intervention do not change any details and click Next.
  25. Issue: For Recommendation, Initial Recommendation is now changed to 'Maintain in out of home care' despite no changes being made to the Safety Interventions.

Resolution:

This issue has been resolved and the correct Initial Recommendation continues to be displayed in the above scenario even if the caseworker uses the Back and Next buttons to navigate back and forth.

Known Issues

See the Known Issues section in the 7.0.10.0 release notes.

Notices

Before using this information and the product it supports, read the information in "Notices"

CSV Release Notes

ReleaseNotes_7.0.11.0.csv

This CSV file summarizes the individual release notes documented above in the "Improvements, Resolved Issues and Third Party Updates" section. The individual release notes documented above will be maintained and will reflect the latest version of the release notes from eGA onwards. However, the content of this CSV file is valid on eGA date, but is not maintained after that.

Additional PDF for WorkItem 262741

Guide_Cascade_NonMagiToMagi.pdf

This PDF file summarizes the details of the new hook point and provides guidance on implementing cascading eligibility

Document Information

More support for:Merative Social Program Management

**Software version:**7.0.11

**Operating system(s):**Linux, Windows

**Modified date:**23 May 2022