Calculation rule: Input relevance and validation

1. Relevance and Condition properties of calculation rules (example: https://openimis.atlassian.net/wiki/spaces/OP/pages/2250473529/FS+calculation+rule+1+contribution+valuation#list-of-impacted-class-and-parameters) have to be considered when displaying calculation parameters inputs.

2. Relevance can have a value of “True” or ”False”:

   1. if “True” the input is to be displayed

   2. if ”False” the input should remain hidden

3. Condition stores a validation formula of a to-be-defined structure. This formula should be used to validate the input and block saving the calculation parameter which turns out to be invalid. A structure of the stored string has to be defined. It will have to be followed when creating new calculation rules.

Selected approach for handling “relevance”

1. Value of relevance is a boolean value and if:

   1. true, then calculation parameter input is displayed and condition is evaluated to determine the validity of the input

   2. false, then calculation parameter input is not displayed and condition is not evaluated - the input is considered valid

Selected approach for handling “condition”

1. Condition formula, stored in condition property of calculationRuleObjectList object, is parsed and evaluated using https://github.com/handsontable/formula-parser. Therefore formulas have to follow the structure defined by this library. Formula evaluation should always return a boolean value:

   1. true if a condition is satisfied

   2. false if else

2. To use calculation parameter value in a formula, INPUT keyword has to be used in the formula. As the parser parses the formula, INPUT string is replaced with the value of the calculation parameter.

3. To use object/entity (PHInusree/CDetails/...) in a formula, OBJECT. prefix, followed by object’s/entity’s property name has to be used in the formula. OBJECT. string is reserved only for this purpose. Please note that after OBJECT there is a dot (.).

4. Object/entity variables/properties can be accessed using dot-notation. If one wants to use value of isDeleted variable/property of an object/entity (PHInusree/CDetails/...) in the formula, he puts OBJECT.isDeleted. What is important is that the string (here: isDeleted) has to match the GQL object's property name. If isdeleted, ISDELETED etc. is used, the solution does not work.

5. Dot-notation can be used to access nested variables/properties of object's properties. For example if PHInsuree ID is needed in the formula it can be accessed by putting OBJECT.insuree.id in it. There is no depth limit, however, if any property name at any level does not match any name from properties of currently accessed object, the retrieved value will be null. An OBJECT (PHInsuree for example) has to have insuree property, where insuree has to have id property.

6. If validation fails, Value validation failed error is displayed under the calculation parameter input.

7. Result of validation can be returned from CalculationInputclass and used to block form submission if setJsonExtValid function is passed as a prop. The function has to accept one argument of type boolean. This argument will be:

   1. true if the condition is satisfied

      1. if > 1 conditions - if all conditions are satisfied

   2. false if the condition is not satisfied

      1. if > 1 conditions - if at least one of the conditions is not satisfied

under the hood

the Dot-notation in the formula is replaced with upper-case string, separated with _, because https://github.com/handsontable/formula-parser formula parser does not allow variables ( ) to contain . sign. Therefore OBJECT.insuree.id in the original formula is replaced with INSUREE_ID. As a result a retrieved value (here: id of insuree of PHInsuree) is assigned to a parser variable INSUREE_ID. As the parser parses the formula, INSUREE_ID string is replaced with the retrieved value.