# Calculation rule: Input relevance and validation

`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.`Relevance`

can have a value of`“True”`

or`”False”`

:if

`“True”`

the input is to be displayedif

`”False”`

the input should remain hidden

`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”**

Value of relevance is a

`boolean`

value and if:`true`

, then calculation parameter input is displayed and`condition`

is evaluated to determine the validity of the input`false`

, then calculation parameter input is not displayed and`condition`

is not evaluated - the input is considered valid

**Selected approach for handling “condition”**

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:`true`

if a condition is satisfied`false`

if else

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.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 (`.`

).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.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.If validation fails,

`Value validation failed`

error is displayed under the calculation parameter input.Result of validation can be returned from

`CalculationInput`

class 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:`true`

if the condition is satisfiedif > 1 conditions - if all conditions are satisfied

`false`

if the condition is not satisfiedif > 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 (https://github.com/handsontable/formula-parser#setvariablename-value ) 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.