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 displayed
if ”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 satisfied
if > 1 conditions - if all conditions are satisfied
false
if the condition is not satisfied
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 (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.