Merative ™ Social Program Management 7.0.9.0 iFix7

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

Release Notes

Abstract

Merative Social Program Management 7.0.9.0 iFix7 Release Notes

Content

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

Introduction

Welcome to the Merative Social Program Management 7.0.9.0 iFix7 release.

This is a cumulative release which incorporates the Improvements, Resolved Issues and Third Party Updates contained in all previous 7.0.9.0 iFix releases. Details of these Improvements, Resolved Issues and Third Party Updates are included separately in the release notes for each of the previous iFix releases.For the latest version of the release notes, see https://curam-spm-devops.github.io/wh-support-docs/spm/release-notes

Full product documentation can be found in the Product documentation and PDFs.

System Requirements

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

Download

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

Installation

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

The installation steps are as follows:

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

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

Upgrading

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

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

Improvements, Resolved Issues and Third Party Updates

Third Party Updates

WorkItem:267834 - Update the versions of the Jackson JARs to the latest version - 2.12.1

The Jackson API contains multiple functions to read and build JSON using Java. It has very powerful data binding capabilities and provides a framework to serialize custom Java objects to JSON strings and deserialize JSON strings back into Java objects. The Java Development Environment (JDE) and the REST infrastructure utilizes these utilities.

The versions of these JARs have now been updated from 2.10.2 to the latest version. As a result of this upgrade, the following changes have been made in the JDE and REST deliverable.

• CuramSDEJ\lib\third_party_version.properties - the versions of the specified Jackson JARs have been updated.
• CuramSDEJ\lib\jackson-annotations-2.12.1.jar - new JAR added.
• CuramSDEJ\lib\jackson-core-2.12.1.jar - new JAR added.
• CuramSDEJ\lib\jackson-databind-2.12.1.jar- new JAR added.
• CuramSDEJ\lib\jackson-annotations-2.10.2.jar - old JAR removed.
• CuramSDEJ\lib\jackson-core-2.10.2.jar - old JAR removed.
• CuramSDEJ\lib\jackson-databind-2.10.2.jar- old JAR removed.
• CuramCDEJ\lib\ext\jar\jackson-annotations-2.12.1.jar - new JAR added.
• CuramCDEJ\lib\ext\jar\jackson-core-2.12.1.jar - new JAR added.
• CuramCDEJ\lib\ext\jar\jackson-databind-2.12.1.jar - new JAR added.
• CuramCDEJ\lib\ext\jar\jackson-annotations-2.10.2.jar - old JAR removed.
• CuramCDEJ\lib\ext\jar\jackson-core-2.10.2.jar - old JAR removed.
• CuramCDEJ\lib\ext\jar\jackson-databind-2.10.2.jar - old JAR removed.
• EJBServer\components\Rest\restlib\dependencyLibsExt\jackson-annotations-2.12.1.jar - new JAR added.
• EJBServer\components\Rest\restlib\dependencyLibsExt\jackson-core-2.12.1.jar - new JAR added.
• EJBServer\components\Rest\restlib\dependencyLibsExt\jackson-databind-2.12.1.jar - new JAR added.
• EJBServer\components\Rest\restlib\dependencyLibsExt\jackson-annotations-2.10.2.jar - old JAR removed.
• EJBServer\components\Rest\restlib\dependencyLibsExt\jackson-core-2.10.2.jar - old JAR removed.
• EJBServer\components\Rest\restlib\dependencyLibsExt\jackson-databind-2.10.2.jar - old JAR removed.

It should be noted that any references in custom scripts and other artifacts to the updated JAR files listed above should be updated.

Cúram Enterprise Framework

Integrated Case Management

ELIGIBILITY & ENTITLEMENT

WorkItem:268435 - Improve reassessment performance when using CER rules

Issue Description:

During a case reassessment, EvidenceDescriptor records for the case are read as multiple single reads resulting in increased load on the database.

During a case reassessment, the following two entity reads are executed unnecessarily during case reassessment, resulting in increased load on the database:

• EvidenceChangeHistory.readUserForLatestChange
• EDApprovalRequest.readCurrentApprovalRequestDetails

User Interface Impact:
No

Steps to Reproduce:
N/A
This issue is dependent on user data and as such is not directly reproducible.

Resolution:

To address issues with performance, the approach to retrieving static evidence has now been enhanced and it is now possible to disable two reads that retrieve unneeded data during a reassessment.

Current caching within Evidence Descriptors is as follows. SQL searches from the EvidenceDescriptor table which include case ID or succession set ID result in all the EvidenceDescriptor records for the case being cached in the current transaction. The first read populates the cache and subsequent reads in that transaction will fetch the records from the cache. The three transaction level caches which store this data are as follows:

• curam.cache.transaction-group.evidencedescriptorcache.bycase
• curam.cache.transaction-group.evidencedescriptorcache.byrelatedidandtype
• curam.cache.transaction-group.evidencedescriptorcache.successionIDToCaseID

As with all transaction level caches, each of these can be tuned with a timeToIdle and/or timeToLive setting.
By default this cache mechanism is enabled. If necessary it can be disabled by adding the following application property:
curam.evidence.evdescripcache.disabled=TRUE

To address this issue with performance a change was made to the following two entity reads which are now suppressed during a reassessment to improve the case reassessment transactions.

• EvidenceChangeHistory.readUserForLatestChange
• EDApprovalRequest.readCurrentApprovalRequestDetails

For all other transactions these reads are executed as normal.

If necessary, the suppression of either of these reads can be disabled by setting the following two application properties respectively:

• curam.evidence.disable.suppress.userforlatestchange=TRUE
• curam.evidence.disable.suppress.evidenceapprovalrequeststatus=TRUE

WorkItem:268598 - Performance optimization for method CaseNomineeObjective.searchObjectiveHistoryForCase

Issue Description:

Bulk reassessment after rate and threshold changes as well as online reassessments resulting from evidence changes sometimes run slowly.
This is due to the performance of the SQL query for method CaseNomineeObjective.searchObjectiveHistoryForCase that can show up as having a very high CPU consumption in the Oracle Automatic Workload Repository Report.

User Interface Impact: No

Steps to Reproduce:

This change relates to a performance optimization of the CaseNomineeObjective.searchObjectiveHistoryForCase API.
It is highly dependent on user data and as such is not directly reproducible.

Resolution:

The SQL query has been refactored into two separate queries and the version of the query which is used now depends on whether the toDate parameter is specified. This enables the database to apply the most optimal access plan for the query.

Cúram Modules

WorkItem:268444 - External user who is member of only Provider 1 can access few details for Provider 2 by intercepting the request and modifying the ConcenroleID

Issue Description:

In the Provider Management self service application, an external user who is a member of a provider should only have access to details related to the provider of which they are member. However, if this same external user knows the concern role identifier of another provider, they can access some information and functions of another provider by supplying that provider's concern role identifier in the URLs of some of the pages contained within the self service external application. This should not be permitted.

User Interface Impact: No

Steps to Reproduce:

1. Login to application as a Caseworker user.
2. Register two people.
3. Login to application as an Administrator user.
4. Navigate to Users section, then select New External User.
5. For person 1 from above, enter the required details. In the Application field select ExternalProviderCustomHome as the application homepage, in the Role field select 'ExternalUserSecureRole', and enable the account.
6. Select the 'Link a Participant' action from the tab actions menu. In the External User's Relationship field select 'Is associated with'. Search for Person 1 and save.
7. Repeat steps 4 - 6 for person 2.
8. Login to application as a 'Provider Management Resource Manager' user.
9. Enroll and approve two providers.
10. Navigate to the Provider Members page under the Relationships tab and add Person 1 from above as a provider member to Provider 1. In the Role field select 'Employee'.
11. Add the Person 2 from above as a provider member to Provider 2.
12. Login to CPM External Application as the newly created External User 1 from Step 4. URL: https://<server_name>:<port_number>/CPMExternalS
13. Navigate to My Details -> Service Enquiries
14. Right click somewhere on the page (below the heading) and select “View Frame Info”
15. Observe the URL under “Address” and write down the concernRoleID number from concernRoleID URL parameter. This should be concernRoleID of Provider 1.
16. Login to CPM External Application as the newly created External User 2 from Step 4.
17. Navigate to My Details -> Service Enquiries.
18. Right click somewhere on the page (below the heading) and select “View Frame Info”.
19. Copy the URL listed under “Address” into a new browser window, but substitute concernRoleID number with the concernRoleID from Provider 1.
20. Issue: The page is accessible, while it should give a user permissions error.
21. This is true for the following pages: Financials -> Transactions, Rosters, Facility -> Reservations, Facility -> Wait Lists.

Resolution:

External users can now only view the details for providers for which they are a provider member.

Technical:

This issue occurred due to the lack of a user permissions check in some of the facades used to service these pages in the Provider Management self service application.
This issue has been resolved by adding a permissions check to the following facades:

• MaintainExternalServiceEnquiry.listWebServiceEnquiries
• ExternalProvider.readProviderSummaryDetails.

A new facade, ExternalProviderFinancial.listFinancialTransactions, has been added which contains the permissions check and this is now called from the following pages:

• PME_listProviderPaymentTransactions
• PME_listProviderGroupPaymentTransactions pages

Note that the page MyDetails -> Requests, and the actions "New Service Invoice Request", "Request Member Login Credentials", and "Change Password" do not show the error message. This is correct behavior as the data is always displayed for the logged in user due to these facades not requiring a concernRoleID as a parameter and are thus not affected by this issue. As a result, if Provider 1 is logged into the CPM self service application, but an attempt is made to pass in the concernRoleID of Provider 2 for these specific pages and actions, the data specific to Provider 1 will still be displayed.

Known Issues

See the Known Issues section in the 7.0.5.0 release notes.

Notices

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