...
UC14-1: add a new Calculation rule (needs to change the openimis.json).
UC14-2: use the frontend contribution_fe to select a calculation rule.
UC14-3: use the fronend contribution_fe to display the parameters required by multiple calculation for an object.
UC14-4: replace a calculation rule.
UC14-5: remove a calculation rule.
...
<list>JSONObject objects {class:"className", main:True/False ,'parameters':['type':"int",'name':"example",'label':{'en':'DiplayName'},'rights':{'read':"readAuthority", ‘write'write':"writeAuthority"},relevance:"frontendjsdisplaylogic",condition:"frontendjsvalidationlogic",'optionSet’:[]]} // list of the parameters required on other object,
relevance and condition are Nice to have.
Methods
ready()
This method makes sure the calculation is registered in the calculation table (if not the line should be added with "inactive status") and register the signals only if it is active
...
This function is required because the same class can have different calculation based on the object members values (like product ….)
(TDC)calculateEvent(sender, instance, user, **kwargs)
This method runs the calculation based on the object sending the signal, this means that the relationship with the other item required for the calculation could be found from the object sending the signal. (e.g., link to the product can be found in the policy as foreign key.)
This function should call first the activeForObject method, the context will depend on the calling event, if the fuction return true the calcuation needs to be run, in other case the even handling will stop
the calculate(*args) function
Signal need to be set up on the ready function to call it
...
Calculations Frontend Module
(NICE TO HAVE, or via Django Admin)Calculation management page
This page will show the calculation page and change the status/activate a given version
This page should group the calculation by UUID
...
Standard contributions should be available for most of the entities (claims, contribution, contribution collection, policies, insuree ....)
PH insuree
C details
Cp
All the other are NICE TO HaVE
Those contributions should get the parameters template from the backend and display the relevant ones. The values should be saved in the JsonExt fields
...
either by wrapping the fe contribution from the rules in a “overall calculation fe contribution“ (this will require rebuilding the front end when adding a rule)
by managing all the rule fe contributions directly within the calculation fe contributions using the parameters defined in the rules (preferred solution)
only simple type should be supported:
int
choice list (key(int)-> value([lang-strings]))
double/float
checkbox
refresh logic should be based on the link between the entity having the contribution and the entity that hold the calculation
Appearance/logic of the data should be defined based:
on the entity
on the rules related to this entity (directly or not)
(nice to have) format should be based on the rule fields constraint (regex)
(nice to have) constraint/ validation should be based on the rule fileds constraint (js test function)
Overall the logic use in enkoto enketo could be reused https://github.com/enketo/enketo-core/blob/e7159f95c5f459efeb83314fdd0aecac78e47400/src/js/input.js
...