PO06895, WorkItem:186435 - UHSE occurs on the Save Information page of an external online application
Issue Description:
Previously, when a user clicked Next on the 'Save Information' page on an external application without choosing the Save or Quit option, and then subsequently choose the Quit option and clicked Next, a unhandled server exception occurred.
User Interface Impact: Yes
Steps to Reproduce:
- Login in as external user.
- Start an application.
- Navigate to the Other Household Members page and answer the question "No".
- Click Save and Exit button. The 'Save Information?' page is displayed.
- Click Next without selecting either option. A validation message is displayed.
- Select the "Quit" option and application proceeds to the home page.
Resolution:
The issue has now been resolved by updating the xml file on this page.
WorkItem:193323 - Tablet Accessibility: Unable to select mega menu items
Issue Description:
Previously, when using an iPad there was an issue with the help menu in Universal Access when VoiceOver was enabled. After opening the help menu (by selecting the (?) icon in the Universal Access banner menu) a user was unable to navigate through and select an item in the help menu while using a keyboard.
User Interface Impact: No
Steps to Reproduce:
- Open up the Merative Social Program Management Universal Access Home page on an iPad device with a keyboard connected.
- Enable VoiceOver.
- With the VoiceOver key held down, navigate focus to the help menu icon (?) using the left and right arrow keys.
- Double tap the screen or hit enter on the keyboard to open the help menu.
Resolution:
This issue has since been resolved. With VoiceOver enabled on an iPad, VoiceOver focus automatically switch to the first menu item in the help menu when the help menu is opened. This allows the user to navigate through items in the help menu and select a value.
PO07697, WorkItem:225585 - Setting X-Content-Type-Options to 'nosniff' causes issues in Universal Access Portal
Issue Description:
On setting the 'X-Content-Type-Options' to 'nosniff' in Merative HTTP Server (via http.conf file), the mandatory field indicator displays 'Mandatory' instead of an asterisk (*) on the Citizen Portal input pages.
User Interface Impact: Yes
Steps to Reproduce:
- Set X-Content-Type-Options to 'nosniff' in http.conf file.
- Login to the Citizen Portal.
- Start an application.
- Note the mandatory fields on the input page.
Resolution:
This issue is now resolved and the mandatory fields now display an asterisk (*) instead of 'Mandatory'.
WorkItem:240711 - Rest API documentation pages are not being generated by Swagger<br/>
Issue Description:
The Rest APIs documentation pages are not being generated by Swagger. An error is thrown during the validation phase of Swagger's build.
User Interface Impact: No
Steps to Reproduce:
- Access the APIs documentation URL: "/Rest/api/definitions/v1"
- An error message is displayed.
Resolution:
All the Rest APIs documentation are now being properly generated.
WorkItem:240713 - Intake Applications - Rest API - Change IntakeApplicationFormAPI.getFormDetails method to return all fields
Issue Description
In certain scenarios the value of submitOnCompletionInd for an IntakeApplicationType was being ignored. This meant that when clicking "Save and Exit" during a script the user would see the popup allowing them to make a partial submission, which should not appear if submitOnCompletionInd is true.
User Interface Impact : Yes. A popup was appearing where it should not.
Steps to Reproduce
- Log in as jamessmith
- Start an application that has submitOnCompletionInd set to true (e.g. Rent Subsidy)
- Click "Save & Exit" during the script
- Choose to save the application
- Verify we are returned to the dashboard
- Resume the newly-saved application
- Click "Save & Exit" button
//
Resolution
The application now respects the value of submitOnCompletionInd and displays.
Appeals
PO07257, WorkItem:200418 - Closing legal action generates unwanted error mails and error messages in the logs
Issue Description
Previously, closing a Legal Action caused unhandled exceptions to appear in the logs and generated unwanted error emails. This was due to CloseCase deferred process not functioning correctly for a Legal Action case type. In the method CloseCase.closeAssociatedRecords, the logic to regenerate financials was always attempted but since legal action cases do not have financials, this resulted in an unhandled exception.
User Interface Impact: No
Steps to Reproduce
- Login as ccscaseworker.
- Create an ongoing case with a few persons.
- Create an external party (court) with Person (judge).
- Make a Petition and a legal petition available for ongoing cases.
- Create legal action using the court and judge and the case persons.
- Close the legal action using for example 'Other' as reason and a comment.
- Look in the curamapplog for the exception.
Resolution
This issue has now been resolved, CloseCase deferred process functions correctly for Legal Action case type. This was achieved by preventing CloseCase.closeAssociatedRecords from regenerating financials for case types that do not have them. It will now regenerate financials for product delivery and liability case types only.
Intelligent Evidence Gathering
PO06595 , WorkItem:173224 - Unknown user displayed in the household income page of an application
Issue Description:
Unknown user displayed in the IEG script when a user has deleted a person from the household on the summary page and then navigated back using navigation panel to Income page in the script.
This is due to the Intelligent Evidence Gathering engine not updating the list of visited pages correctly after an entity has been deleted.
User Interface Impact: No
Steps to Reproduce:
- Log in to the Merative SPM application as hcrcaseworker.
- Register an adult person and create a new application.
- Fill out the details for the primary person.
- Add an adult spouse to the household and fill out the details for that person.
- Add income for both household members.
- Arrive at the summary page.
- Remove the spouse from the household.
- Click on the "Household Income" section in the navigational panel. Notice a tab is displayed for an unknown person.
Note: If you are a customer that does not use the Healthcare Reform Solution, but have configured Intelligence Evidence Gathering scripts as an Intake mechanism, you can reproduce this scenario by configuring a script which allows a user to enter and delete a top-level entity, such as a Person entity, a child entity, such as an Income entity, and which also contains a page which references both those entity types.
Non-Healthcare Reform Steps to Reproduce:
- Open the configured script.
- Fill out all details for primary person and spouse.
- Create an income for each person.
- For each person, navigate through the page which references both entity types.
- Using the navigational panel, go to the section where you can delete a person and delete the last person who was entered.
- Using the navigational panel, go back to the section which contains the page which references both entity types.
Resolution:
The issue has been resolved. Now after deleting the Person from the script the pages that reference a Person entity and child entity are updated accordingly.
PO07802, WorkItem:231314 - Pressing the keyboard 'Enter' key on a combobox with an inline autocomplete suggestion results in a validation error being thrown
Issue Description:
Previously, when navigating an Intelligence Evidence Gathering page using the keyboard only and hitting the enter key on a combobox with an inline autocomplete suggestion, resulted in the page performing the default action and navigating to the next page. This resulted in a validation being thrown if some mandatory fields were not completed.
User Interface Impact: Yes
Steps to Reproduce:
- Log into as a caseworker.
- Register a person and start a new Application.
- Navigate using the keyboard to a combobox input.
- Type the initial letter for a suggested answer in the dropdown.
- Press the enter key to populate the combobox with the autocomplete suggested value.
- The cursor should appear at the end of the text in the combobox.
Resolution:
The IEG page has been updated to properly handle the enter key on the combobox to select the autocomplete suggestion.
PO07815, WorkItem:231716 - Ghost person is being displayed and an application error occurs when a person is removed from HCR application
Issue Description:
An issue exists where an application error can appear while navigating through an Intelligent Evidence Gathering script after an entity has been deleted due to the Intelligent Evidence Gathering engine not updating the list of visited pages correctly.
User Interface Impact: No
Steps to Reproduce:
- Log in to the Merative SPM application as hcrcaseworker.
- Register an adult person and create a new application.
- Navigate through the script, filling out the details for the primary person.
- Add an adult spouse to the household and fill out the details for that person.
- Ensure both household members want to help pay for their own health insurance and benefits.
- Ensure both household members have income and are tax filers.
- Ensure the spouse plans to file a joint tax return with the primary person
- When asked does the household member pay for certain things that can be deducted on an income tax return, leave the question unanswered.
- Navigate to the "Additional Household Information" page and don't select anything.
- Click on the "Household Information" section in the navigational panel.
- Remove the spouse from the household.
- Click on the "Household Income" section in the navigational panel. Notice a tab is displayed for an unregistered person.
- Select "Yes" for the expected annual income question and click "Next".
- On the "Additional Household Information" page, click on the "Household Information" section in the navigational panel.
Note:
If you are a customer that does not use the Healthcare Reform Solution, but have configured Intelligence Evidence Gathering scripts as an Intake mechanism, you can reproduce this scenario by configuring a script which allows a user to enter and delete a top-level entity, such as a Person entity, a child entity, such as an Income entity, and which also contains a page which references both those entity types.
To do this, create a script with a Question Page and Summary Page element which allows a user to create and delete multiple Person entities and a Question Page element which allows a user to enter an Income entity for each person. Then construct a Loop element whose loop type is set to "for-each" and whose entity type is set to Person. Within the Loop element, configure a Question Page element with an entity type set to be the same as the Loop entity type. A Question element within a Cluster element, whose entity type is set to Income, should then be constructed on the Question page.
Non-Healthcare Reform Steps to Reproduce:
- Open the configured script.
- Create a primary person and two additional people.
- Create an income for each person.
- For each person, navigate through the page which references both entity types.
- Using the navigational panel, go to the section where you can delete a person and delete the last person who was entered.
- Using the navigational panel, go back to the section which contains the page which references both entity types.
Resolution:
An application error will no longer appear while navigating through an Intelligent Evidence Gathering script after deleting an entity due to the Intelligent Evidence Gathering engine clearing the list of visited pages correctly.
PO07869, WorkItem:234789 - Outcome plan assessment back button navigation does not return to the previous page as expected
Issue Description:
An issue occurs in Intelligent Evidence Gathering scripts where navigating using the back button does not return to the previous page as expected. This issue occurs when there are one or more pages, whose entity type has been specified to one that was created outside of an Intelligent Evidence Gathering script, for example via a Callout element, but is not referenced by any Question or Cluster elements elsewhere in the script, and where all of the Cluster elements inside those pages have their entity type set to another entity type.
User Interface Impact: No
Steps to Reproduce:
Configure an Intelligent Evidence Gathering script that contains a question page, a summary page and a final landing page, ensuring all pages contain a navigational back button. Configure a Callout element to create an entity of a certain type before the first question page, and set the entity type of the first question page and the following summary page to the same entity type that was created by the Callout. Then configure a Cluster element, which contains a Question element, inside both the question and summary pages, and set the entity type of the Cluster element to be different to the entity type of the page.
- Navigate to the first question page and answer any questions that are present.
- Navigate through the script until you get to the final landing page.
- Click the back button to go to the final summary page.
- Click the back button again and you will arrive on the final landing page again.
- Click the back button again and you will arrive on the final question page.
Resolution:
This issue has now been fixed, and users navigating using the back button will return to the previous page as expected.
WorkItem:240633 - IEG input sanitizing: stripping tags and keeping non-ascii characters
Issue Description:
Previously, when a user entered text into the Merative Social Program Management Universal Access Responsive Web Application, it was not sanitized before it was saved. For example, “Cúram” was transformed to "Cúram”. As a result, the text was unreadable for languages based on non-ASCII characters
User Interface Impact: YES, HTML Tags are removed.
Steps to Reproduce:
- Navigate to a form in Merative Social Program Management Universal Access Responsive Web Application
- Enter a non-ASCII character, i.e “Cúram”, into the form.
- Save the form and view the details on the summary page.
- Note that non-ASCII characters are unreadable, i.e "Cúram”
Resolution:
Now, the sanitization mechanism removes the HTML tags only and non-ASCII characters are readable
Evidence Broker
PO07654, WorkItem:223602 - Exception occurs while trying to broker evidence from a person case to an integrated case by using the old evidence broker in V7.0.2
Issue Description:
While trying to broker evidence from a person case to an integrated case by using an old evidence broker configuration, an unhandled server exception occurs when the user clicks the Incoming Evidence tab.
User Interface Impact: Yes
Steps to Reproduce:
- Log on as sysadmin.
- Set the value of the "curam.aes.advancedEvidenceSharingEnabled" property to "NO" and publish the changes.
- Log on as hcrcaseworker.
- Submit a simple application with a single member with income in the Streamline Medicaid range. Provide the date of birth as 1/1/1980.
- Open the application case Action menu and click Authorize. An integrated case and product delivery case are created.
- At the person level, click Evidence in the shortcuts panel, then edit the Birth and Death Details evidence.
- Modify the date of birth to 1/1/1982.
- Click Save.
- Open the integrated case, then click the Evidence > Incoming Evidence tab. An unhandled server exception message is displayed.
Resolution:
The old evidence broker was deprecated in V7.0.2 and and is disabled by default in the application. To enable the old evidence broker, extra configuration is required in addition to configuring the "curam.aes.advancedEvidenceSharingEnabled" property. The unhandled server exception occurred because the system was reverted back to use the old broker without changing the UI configuration to use the old Incoming Evidence UI, it was trying to use the new Incoming Evidence UI.
All configuration steps are now described in the "Enabling Evidence Broker 1" section in the Upgrade Helper Guide. For more information, see
https://curam-spm-devops.github.io/wh-support-docs/spm/pdf-documentation
PO07891, WorkItem:236110 - Incoming Evidence page does not display correct dates when a user's timezone is not Coordinated Universal Time (UTC)
Issue Description:
The Incoming Evidence page is not displaying the correct dates in the Incoming Evidence or Existing Evidence timelines when a user's timezone is set to a different timezone other than Coordinated Universal Time (UTC). This causes the 'Update with Incoming' evidence modal and 'Set as Latest of Incoming' evidence modal to not correctly display incoming evidence due to the incorrect dates being used in the timelines.
User Interface Impact: Yes
Steps to Reproduce:
The issue occurs on the Incoming Evidence screen for all cases. The steps below require prerequisite setup in Admin; login to Admin and create an Integrated Case called Social Assistance and add email evidence to this case.
- Change the client machine's timezone to EST, e.g. New York.
- In Admin; check to ensure there is no identical sharing configuration setup for Social Assistance - Email > Social Assistance - Email.
- Register a person.
- Create a Social Assistance case for that person (Case 1).
- Add email evidence with a start date of yesterday & apply changes.
- Create another Social Assistance case for that person (Case 2).
- Login to Admin and now add identical sharing configuration of Social Assistance - Email > Social Assistance - Email.
- Login as caseworker again and add email evidence to Case 2 with a start date of today & apply changes. This will trigger Advanced Evidence Sharing (AES) but as the two Email evidences can't be reconciled it will be added to the Incoming Evidence list.
- Open the Incoming Evidence page on Case 1 and toggle the Email evidence inline page. The start date on both the incoming and the existing evidence will be correct, but the dates shown in the timeline will be a day earlier.
- Selecting 'Update with Incoming' or 'Set as Latest of Incoming' from the existing Email's actions will display a modal with an empty evidence list.
Resolution:
The Incoming Evidence page will now take the browser's timezone into account and display the correct dates on the Incoming Evidence and Existing Evidence timelines.
Technical:
The issue was addressed by updating the following file
- ../Curam/components/AdvancedEvidenceSharing/WebContent/CDEJ/jscript/aes/BusinessObjectViewer.js
to include a _getDate(dateString) function which formats dates in the browser's timezone.
Financial Management
PO04061, WorkItem:103256 - System does not allow creation of a deduction when there is an active deduction with the same name and overlapping dates
Issue Description:
The system prevented the creation of a deduction when an active deduction with the same name and overlapping dates existed on the system for the same case. This occurred despite the 'prevent overlapping' flag being set to false for the underlying product.
User Interface Impact: No
Steps to Reproduce:
- Set up a Liability Repayment deduction on a product with the prevent overlapping flag set to false.
- Set up a product delivery to deliver this product and generate payments on it.
- Modify the evidence to create an over-payment.
- Create a deduction on the product delivery to offset the over-payment, but don't activate it.
- Create a second deduction on the product delivery to offset the over-payment, but don't activate it.
- Activate the first deduction.
- Activate the second deduction.
- Create a third deduction against the over-payment with dates which overlap with one or other of the first two deductions - an error is reported to the case worker preventing them from creating the deduction due to an existing overlapping deduction.
Resolution:
The process for setting up a deduction was treating an informational as an error, which prevented a caseworker from completing the set-up steps. It is now possible to create multiple overlapping deductions with the same name when the 'prevent overlapping' flag is set to false for the underlying product.
Technical:
The issue was caused by a call to the Informational Manager failOperation API when it contained a warning, when it should only be called when the type of informational contained within the Informational Manager is of type 'Error' or 'Fatal Error'. Warnings should not prevent the transaction from completing, instead the warning should be returned as an informational, which can be achieved by wrapping the call to the failOperation in an API that checks explicitly for these types.
The fix for the reported issue introduces an API to wrap the call to failOperation and performs an explicit check for informationals of type 'Error' and 'Fatal Error'.
It is now possible to create multiple overlapping deductions with the same name when the 'prevent overlapping' flag is set to false for the underlying product.
Identity Intelligence
WorkItem:232534 - Merative SPM is now certified to use IBM InfoSphere Identity Insight 9.0.0
The IBM InfoSphere Identity Insight (II) product analyzes participant data that is collected from the Merative SPM system. The product checks if similar or suspicious identities exist in the participant data. An analysis takes place to indicate a risk of fraud, waste, or abuse when a caseworker enters or works with one candidate.
The version of the IBM InfoSphere Identity Insight product certified for usage with SPM has been updated from 8 to 9.0.0. There were a number of changes made as part of the II version update.
1. Identity Insight's authentication framework has been standardized to take advantage of the many authentication options provided by WebSphere Liberty. As a result of this the following is required to connect to the II service:
- a user name must be specified
- a password must be specified.
To allow the user name and password to be configured by customers, the following dynamic application properties have been introduced which allows the user name and password to be used for InfoShere Insight integration to be set and changed as required.
- curam.programIntegrity.II.username
- curam.programIntegrity.II.password
2. Merative Social Program Management uses web services to connect to the Identity Insights instance to pass data to that services and retrieve the results. These web services are delivered as part of an II installation and the associated WSDL files must be taken onto SPM (EJBServer\components\ProgramIntegrity\wsdl) and the relevant web services stubs generated from them.
The following two II WSDL files have been updated and the associated web services regenerated to ensure compatibility with the new version of II:
- EntityResolver.wsdl
- srd.wsdl
Solutions
Income Support
Child Welfare
Child Welfare SDM
Common Evidence
Income Support
Assessment and Tracking Return to Work
Food Assistance
Medical Assistance
PO03820, WorkItem:101352 - Incorrect Paid Employment Period Start Date
Issue Description:
When Paid Employment evidence is created on an Income Support integrated case, it is not possible to capture a business start date for the evidence. Because of this, the start date of the case is displayed as the start date for the period for the evidence on the Evidence list pages. This can result in the display of misleading information for the caseworker when the start date of the employment associated to the Paid Employment evidence is not the same as the case start date.
User Interface Impact: No
Steps to reproduce:
- Login as an Income Support caseworker.
- Register a new person.
- Create a new Employment record for the person, with a start date in the past.
- Create a new Income Support integrated case for the person.
- Add Paid Employment evidence to the case to reflect the person's employment.
- The Evidence list pages show the period for the Paid Employment evidence to be from the integrated case start date forward, even though the Employment started in the past.
Resolution:
It is now possible for a different start date to be displayed for the period for the Paid Employment evidence, so that the start date of the related Employment record can be used.
Technical:
A new hook point, EvidencePeriodHook, has been added to the evidence infrastructure to allow customers to override, at an evidence type level, the business start and end dates used for the period on the Evidence list pages. The hook point was added as part of WorkItem: 123096. An implementation of this hook can be provided for the Paid Employment evidence type to allow for the return of the associated Employment start and end dates. The custom implementation will then need to be bound to the evidence type.
PO06440, WorkItem:166062 - Outstanding verification cannot be created for Contributor Evidence configured at PD level
Issue Description:
A mandatory verification on the Expense Amount attribute of the Contributor evidence configured at the product delivery level does not get created.
Setting of the verification at the product delivery level is dependent on a case participant being present in the evidence hierarchy, as the logic reads back up through the hierarchy as far as it can to find a case participant attribute. If it finds none, then there is no value available for creating the product delivery verification.
User Interface Impact: No
Steps to Reproduce:
- Login as an administrator.
- Enable mandatory verifications for the product delivery, for example for Food Assistance, Cash Assistance, or Medical Assistance.
- Configure verifications for evidence, for example for Contributor.
- Login as an Income Support caseworker, and submit an application for a parent and child who are determined eligible for the product delivery configured above.
- Create the evidence configured above.
- Check the Verifications tab on the product delivery and see that the mandatory outstanding verifications are not created for the evidence.
Resolution:
Now, a mandatory verification on the Expense Amount attribute of the Contributor evidence configured at the product delivery level is created.
Technical:
A fallback mechanism has been incorporated into the static evidence generator for structures where no case participant exists. In this instance, a case participant associated with the evidence descriptor is used instead to guarantee that the product delivery verification gets created. The issue has been addressed by an update to the static evidence generator. This was addressed in WorkItem: 234258.
WorkItem:185477 - When a new member is added to an Income Support application using the 'Add a Member' Guided Change wizard, the user is incorrectly navigated to an integrated case
Issue Description:
A caseworker can add a new member to the household within an Income Support application using the 'Add a Member' guided change wizard. When the caseworker completes the 'Add a Member' wizard, the caseworker is incorrectly navigated to the Guided Change page within an Income Support integrated case, rather than to the Guided Change page within the Income Support application.
User Interface Impact: Yes
Steps to Reproduce:
- Login as an Income Support caseworker.
- Create an Income Support application.
- Add a new member to the application by selecting the Guided Change > Add a Member action item from the tab level action menu.
- Complete the 'Add a Member' wizard.
- A new tab for an Income Support integrated case is incorrectly opened and the user is navigated to the Guided Change page within the integrated case.
Resolution:
When the caseworker adds a new member to an Income Support application using the 'Add a Member' guided change wizard, the caseworker is now correctly navigated to the Guided Change page within the Income Support application.
Technical:
The out-of-the-box summary page for the 'Add a Member' Guided Change wizard is ISAddMemberWizard_summaryDetails. This previously redirected the user to the CREOLEIntegratedCase_listGuidedChange page, which is associated with the Income Support IC tab. The logic has been updated to determine, on submission, where the Guided Change began and redirect appropriately. The functionality now redirects to either
- CREOLEIntegratedCase_listGuidedChange (for integrated cases) or
- ISPApplication_listGuidedChange (for application cases)
WorkItem:222596 - Removal of Concurrent Eligibility 7.0.3 Refresh Pack Application Properties
Issue Description:
Previously the feature that detects concurrent eligibility for Food Assistance and Cash Assistance was configurable through application properties and was turned off by default to support its initial release in the 7.0.3 refresh pack.
Two additional application properties were also available to control whether validations related to program authorization should occur or not and were also turned off by default.
User Interface Impact: No
Steps to Reproduce: N/A
Resolution:
The following application properties have now been removed as they were only intended for refresh pack purposes:
- Dual Detection Enabled Indicator for Cash Assistance
- curam.isproduct.cashassistance.dualdetection.enabled
- Determines whether Cash Assistance rules check for concurrent eligibility when determining client eligibility. When the value is 'YES', concurrent eligibility is checked.
- Dual Detection Enabled Indicator for Food Assistance
- curam.isproduct.foodassistance.dualdetection.enabled
- Determines whether Food Assistance rules check for concurrent eligibility when determining client eligibility. When the value is 'YES', concurrent eligibility is checked.
- Override the authorization validation for end-dated members
- curam.isproduct.dualparticipant.enddatedhhmember.authoverride.enabled
- When Food Assistance or Cash Assistance is authorized, determines whether the authorization should be allowed when an applicant is a case member on another case of the same type that does not have a status of closed but has left the household. When the value is 'YES', the system overrides the authorization validation and authorization is allowed.
- Override Food Assistance authorization validation for member living in a domestic violence situation
- curam.isproduct.foodassistance.dvauthoverride.enabled
- When Food Assistance is authorized, determines whether the authorization should be allowed when an applicant is a case member on another Food Assistance case that does not have a status of closed, but has living arrangement evidence of type 'Shelter for Battered Women and Children' on the new application. When the value is 'YES', the system overrides the authorization validation and authorization is allowed.
The following guide that references the configuration options has also now been updated:
- Configuring concurrent eligibility detection in the Configuring Income Support section.
link:
https://curam-spm-devops.github.io/wh-support-docs/spm/pdf-documentation
PO07740, WorkItem:227613 - Helper text pop up message displays 'null' or blank text
Issue Description:
Four questions from the case management intake script are missing their corresponding help-texts.
User Interface Impact: Yes
Steps to Reproduce:
- Login as an Insurance Affordability caseworker and start a new application.
- Navigate to pages where the following questions are asked and click on the help icon for the following questions.
- 'Do you have a fixed address?'
- 'Is the mailing address the same as home address?'
- 'Does <participant> have an SSN?'
- 'Does this person want to find out if they can get help paying for their own health insurance and health benefits?'
- Help text is not displayed for these questions.
Resolution:
The missing help-texts have been added to the IEG script XML files and to the corresponding properties files.
WorkItem:228872 - Add a Member Guided Change wizard is not correctly saving primary caretaker information entered in the Relationship Details page
Issue Description:
When adding a member to a household using the 'Add a Member' guided change wizard on an Income Support case, the caseworker can select a Primary Caretaker indicator on the Relationship Details page to indicate that the new member being added is the primary caretaker of an existing household member as part of establishing a relationship between the two members. When the caseworkers selects the Primary Caretaker indicator and completes the 'Add a Member' wizard the information is not saved to the Household Relationship evidence that is created at the end of the process.
User Interface Impact: No.
Steps to Reproduce:
- Login as an Income Support caseworker.
- Create an Income Support integrated case.
- Add a new member to the household by selecting the Guided Change > Add a Member action item from the tab level action menu.
- On the Relationship Details page, indicate that the new member is the primary caretaker of an existing household member.
- Complete the wizard.
- Navigate to the Evidence Workspace and view the Household Relationship evidence that was created.
- The 'Primary Caretaker' indicator is not set to 'Yes'.
Resolution:
The 'Primary Caretaker' indicator is now correctly populated when the Household Relationship evidence is created.
PO07893, WorkItem:236133 - Dual Eligibility Report batch process fails when run on a different deployed machine
Issue Description:
When the application is built and deployed on different locations (e.g. built on server A in C: drive and deployed on server B in D: drive), running the Dual Eligibility Report batch process may fail.
User Interface Impact: No
Steps to Reproduce:
- Build EJBServer
- Deploy to Server with different path
- Run the Dual Eligibility Report
Resolution:
The issues occurs because the report uses CER Generated Rule Classes to reference CashAssistanceRuleSet.CADualDetectionCalculator and FoodAssistanceRuleSet.FADualDetectionCalculator. The generated classes are intended only for use by test code and are not supported in production.
An implementable interface has been removed as part of this change as it exposed the generated rule classes in the contract, and has instead been replaced with a compliant approach.
- Removed: curam.isproduct.creole.dualdetection.batch.report.dualeligibility.impl.DualDetectionCalculatorFactory
- Replaced with: curam.isproduct.creole.dualdetection.batch.report.dualeligibility.impl.DualDetectionCalculator
The batch report is intended only as an admin tool for understanding existing cases of Dual Eligibility. Where custom implementations have been provided for DualDetectionCalculatorFactory the following should be noted:
- The implementation will fail to compile now that the interface DualDetectionCalculatorFactory has been removed
- A new implementation should be made implementing the DualDetectionCalculator interface
- The new implementation must be bound to the Product type code in place of the existing DualDetectionCalculatorFactory binding. This will ensure the report runs for any custom products the DualDetectionCalculator has been implemented for.
PO07948, WorkItem:238564 - Error occurs when selecting the 'Open in New Tab' function on the Verifications page
Issue Description:
On an Income Support integrated case, clicking on the 'Open in New Tab' page level action on the evidence Verifications page throws an error.
User Interface Impact: Yes, the 'Open in New Tab' page level action menu is removed from the evidence Verifications page for Income Support.
Steps to Reproduce:
- Login as an Income Support caseworker.
- Register a person and create an application for Food Assistance
- Authorize the application.
- Navigate to the Income Support integrated case.
- Navigate to the Verifications page under the Evidence tab.
- Select the 'Open in New Tab' function on the page.
- The following error message is displayed: "ERROR: The page that you are trying to link to is associated with multiple tabs: [CaseEvidence,OutcomePlan]. Therefore the tab to open cannot be determined and the page will open in the current."
Resolution:
The 'Open in New Tab' page level function has been removed from the Verifications page. This was done to ensure consistency between the Insurance Affordability and Income Support integrated cases.
ASSESSMENT AND TRACKING RETURN TO WORK
PO06394, WorkItem:163194 - Unhandled server exception occurs when viewing the Outcome Plan Home page of an outcome plan that includes a new action with no frequency specified
Issue Description:
As part of the Return to Work Outcome Management process in Income Support, clients that are work registered can be referred to a provider and an outcome plan can then be created within the Income Support integrated case to help clients attain self sufficiency. When an outcome plan is created as part of this process, if a user manually adds a new action to the outcome plan and does not specify a frequency for the action, an unhandled server exception occurs when the user attempts to view the Outcome Plan Home page.
User Interface Impact: No
Steps to Reproduce:
- Login as a system administrator and enable geocoding functionality for the Work Referral process.
- Set the curam.miscapp.geocode.enabled application property to 'YES'.
- Set the miscapp.geocode.googlemapsapikey application property to the appropriate Google API Key.
- Ensure that the address for a provider and the address entered for a client during the application process will result in a match during the Work Referral process.
- Login as an Income Support caseworker.
- Create and submit a new application for Cash Assistance for a mother and child that includes work registration and other evidence and that will result in an eligible determination.
- Check eligibility for Cash Assistance to ensure that the determination result is 'Eligible'.
- Navigate to the Work Eligibility tab and create a new Referral for the mother.
- Authorize the application.
- Login as a user that manages the creation of return to work outcome plans.
- Navigate to the Pending Referrals tab under the Outcome Plans section of the Shortcuts menu.
- Search for the referral created for the mother, and assign the referral to the user.
- Navigate to the Income Support integrated case created for the mother.
- Create a new outcome plan of type 'Self Sufficiency Outcome Plan'.
- Within the outcome plan, navigate to the Activities tab and select to create a new action.
- In step 1 of the New Action wizard, do not select any of the pre-defined actions and instead enter a name for a new action.
- In step 3 of the wizard, leave the Frequency field blank.
- Finish the wizard and save the new action.
- Navigate to the Outcome Plan Home page.
- An unhandled server exception occurs.
Resolution:
The Outcome Plan Home page has been updated to correctly recognize manually entered actions that have no frequency and displays correctly.
Technical Details:
The error occurred in the following rules during a call-out to a Statics class:
- Rules (unmodified):
- /EJBServer/components/AssessmentTracking/CREOLE_Rule_Sets/Data/OutcomePlan/ActivityDetails.xml, Attribute scheduledMinutesTimeLine
- Static method (modified):
- curam.assessmenttracking.impl.Statics.determineScheduledTimeLine
The Static method has been updated to return the default zero forever Timeline where no frequency is specified.
FOOD ASSISTANCE
PO06147, WorkItem:152703 - Unhandled Server Exception occurs when editing Household Relationship evidence for a reciprocal relationship
Issue Description:
When a caseworker creates Household Relationship evidence on an Income Support integrated case, reciprocal relationships are automatically created. For example, if a boy and a girl are household members of a case and Household Relationship evidence is added for the boy that indicates that the girl is the sister of the boy, the system automatically creates a reciprocal relationship that indicates that the boy is the brother of the girl.
If a caseworker subsequently attempts to modify the reciprocal Household Relationship evidence record that was created by the system, an unhandled server exception occurs.
User Interface Impact: No
Steps to Reproduce:
- Login as an Income Support caseworker.
- Register a person.
- From the Applications tab of the person record, select 'New Application'.
- Complete an application for Food Assistance that includes two applicants and submit the application. Be sure to tick the checkbox for 'Does this person purchase and prepare food with the claimant?'.
- Navigate to the application case and add the required evidence to make the household eligible.
- Resolve any outstanding verifications.
- Authorize the case and activate the Food Assistance product delivery case.
- Navigate to the Income Support integrated case and edit the 'Household Relationship' evidence record that was created by the system as a reciprocal record for the one entered by the caseworker; specifically change the value of the 'Relationship Type' from the drop-down menu.
- Click Save.
- An unhandled server exception occurs.
Resolution:
This issue has been addressed and it is now possible to successfully modify a Household Relationship evidence record the represents a reciprocal relationship.
MEDICAL ASSISTANCE
WorkItem:103814 - Implementation for the @ProfileMethod annotation for verification services should only print to the system logs when tracing turned on
Issue Description:
The verification services inside Insurance Affordability are annotated with @ProfileMethod. The interceptor implementation of this annotation reported everything to the system logs, regardless of whether tracing was turned on or not. This has the side effect of polluting the logs and making them difficult to interrogate. It also reduces the scalability of the system.
User Interface Impact: No
Steps to Reproduce:
- Login as an Insurance Affordability caseworker.
- Create an Insurance Affordability application for a person.
- Submit the application.
- An examination of the system logs will show that it will contain logging information for the verification services that are called.
Resolution:
The implementation associated with the @ProfileMethod annotation in Insurance Affordability for the verification services has been updated to only write to the system logs when the tracing is turned on. Nothing is written to the logs when tracing is turned off. Additionally, the JMX infrastructure is used to capture the performance stats associated with the verification services.