CUSTOM IMPLEMENTATION OF SECURITY PER INTEGRATED CASE TYPE

Hi Garry,

We have reviewed your enhancement suggestion. Based on the information provided, our understanding of your request is as follows:
You require a way to call the "OOTB implementation" code* from the custom CaseTypeSecurity implementation.

For example, if the "OOTB implementation" code in the else block** was factored out into an external API that could be called, this would satisfy the requirement.

This would mean that the custom CaseTypeSecurity implementation would still get called for all integrated case types. And if the case type was anything other than 'Complaint', the "OOTB implementation" code could be called directly by the custom code. Otherwise, custom processing would take place instead (assuming some other custom conditions are also met).

*To be specific, the "OOTB implementation" code is in the 'else' block of curam.core.impl.OnlineSecurityImplementation.checkCaseSecurity1(CaseSecurityCheckKey).
**The 'else' block that is being referred to in this case is the block executed if there is no custom implementation found i.e. where caseTypeSecurity is null.

The theme is aligned with our current multi-year strategy for our product and we have accepted your suggestion as a consideration for a future release. Not all items under consideration will make it into a release. As plans are confirmed, you will be notified when a specific release includes this enhancement.

Thank you for taking the time to share your ideas with us. We are committed to involving our users in building our product roadmap and appreciate your suggestions.

Regards,
Shane McFadden, Cúram SPM Product Management team

Spot on, yes that 's it exactly thanks Shane

Hi Garry,

Thank you for the response.

Could you please confirm our understanding of the enhancement request below?

The project requires a way to call the "OOTB implementation" code* from the custom CaseTypeSecurity implementation.

For example, if the "OOTB implementation" code in the else block** was factored out into an external API that could be called, this would satisfy the requirement.

This would mean that the custom CaseTypeSecurity implementation would still get called for all integrated case types. And if the case type was anything other than 'Complaint', the "OOTB implementation" code could be called directly by the custom code. Otherwise, custom processing would take place instead (assuming some other custom conditions are also met).

*To be specific, the "OOTB implementation" code is in the 'else' block of curam.core.impl.OnlineSecurityImplementation.checkCaseSecurity1(CaseSecurityCheckKey).
**The 'else' block that is being referred to in this case is the block executed if there is no custom implementation found i.e. where caseTypeSecurity is null.

Thank you,
Shane McFadden, Cúram SPM Product Management team

Hi Garry,

Thank you for providing the additional information requested. Within the next 30 days we will review the details you have provided and inform you of our analysis and decision.

Regards,
Shane McFadden, SPM Offering Management team

Have had a proper look at this now. I'll try to restate it, apologies if it wasn't clear earlier. Happy to have a call to discuss further if needed. In fact even if there was a mechanism for custom per IC TYPE, it still wouldn't be enough - see below.

As mentioned, we have different types of Integrated Case - LIB, Disability, Complaint, Redetermination etc

We only need the custom functionality for one case - Complaint, and even then, NOT in all cases.

We need the functionality to be :

IF (Case type = IC - Complaint AND custom logic to check access = false)
return ‘no access'
ELSE
call OOTB checkCaseSecurity1()

I.e. for most cases we want to just call the OOTB code.

If I understand the CaseSecurityCheck injection, the OOTB code does something like:

IF custom implementation
Call custom implementation
Do Some Logging
return
ELSE
“OOTB implementation”
Do Some Logging
return

Issue here is that to achieve our requirements, we would have to copy all of the “OOTB implementation” to our custom class.
So although we would achieve the compliancy of not doing replace superclass, we would still need the uncompliant copy and paste of OOTB code.

For the custom class to work, the OOTB code would have to be made available.

Admittedly, the approach is slightly better, but not fully compliant

Hi Garry,

If the same rules are to be applied to all Integrated Cases, then there shouldn't be any need to re-implement the same solution for any new Integrated Case types.

For example, create a custom CaseTypeSecurity implementation as follows:

--------------------------------------
public class CustomCaseSecurityImpl implements CaseTypeSecurity {

@Override
public DataBasedSecurityResult
checkCaseSecurity1(final CaseSecurityCheckKey key)
throws AppException, InformationalException {

System.out.println(
"Add custom checks here for all custom integrated case types...");

// Add custom logic here..

return new DataBasedSecurityResult();

}
}
--------------------------------------


Then bind the implementation in a Guice module for the INTEGRATEDCASE type.

--------------------------------------
...
final MapBinder caseTypeSecurityBinder =
MapBinder.newMapBinder(binder(), CASETYPECODEEntry.class,
CaseTypeSecurity.class);

caseTypeSecurityBinder.addBinding(CASETYPECODEEntry.INTEGRATEDCASE)
.to(CustomCaseSecurityImpl.class);
....
--------------------------------------

The implementation will now get called for all Integrated Case types configured on the system.

If we've misunderstood something, do let us know.

If it would help and/or it's convenient, code snippets/samples can be attached to further clarify the request.

Thank you,
Shane McFadden, Cúram SPM Product Management team

thanks andrew, Shane I had discussed and reviewed this with Andrew, thanks

Hello
I think that the offered solution, using CaseTypeSecurity, is too granular for our needs. What we require is a method for a call out (or the ability to override) checkCaseSecurity as what we must do is perform the same processing for all case types. If we use CaseTypeSecurity on a per case type basis we would have to remember to implement the same solution for all case types. On a rolling project of this size and scope I'm pretty sure that at some point, for some benefit, we would forget. It's also pretty inefficient to have to do this.

So can we have a hook point in checkCaseSecurity please so that we can implement custom processing on a one solution fits all?

Hi Garry,

Thanks for your response, I'll leave the status of this request as 'Need More Information' until we hear back from you.

Thank you,
Shane McFadden, Cúram SPM Product Management team

Apologies for the delayed response.
Its a fair question.
Checking the OOTB code, once the custom version is called it does a whole lot more processing.
Our customisation only needs to do a small bit of processing and skip the OOTB processing, which i think may have been the reason we didn't use it.
Will need to do further checks to confirm this, hence please can you leave it open for now?
Many thanks.

testing as have just lost a load of comments

Hi Garry,

In order to evaluate your request, we require that you provide more detail so that we can fully understand your requirements.

You quoted CaseTypeSecurity as being a way to add security per case type e.g. Integrated Cases. But you would like to be able to extend that to allow for custom security checks for different types of Integrated Cases.

We just want to make sure we understand this one a bit more and the question we have is why you feel you cannot achieve this in their implementation of CaseTypeSecurity.
For example, could the custom implementation for Integrated Cases check to see what the type of Integrated Case is and then perform custom security checks accordingly?

Thank you,
Shane McFadden, Cúram SPM Product Management team

Hi Garry,

Thank you for your enhancement request.
We require some further analysis to determine whether or not this enhancement can be considered in a future release.
I will provide another response when our investigation is complete.

Thank you,
Shane McFadden, Cúram SPM Product Management team