enketo
calculation inside non-first repeat does not run when relevancy changes
Describe the bug
- If a calculation without a form control inside a repeat has a relevancy dependency on another question inside that repeat, it does not get recalculated for certain calculations.
- When the record is validated, any non-relevant calculated values (step 4 below) are not pruned (likely similar cause).
To Reproduce
- Drop repeat-relevant-calc.xml.txt into test/forms (change extension to xml) and run http://localhost:8005/?xform=repeat-relevant-calc.xml (fyi, see also the XLSForm)
- Leave first repeat untouched and enter 8 in the 2nd repeat.
- See that the calculation result (1 + 1) does not update in the 2nd repeat. It should!
- Enter 9 in the first repeat and see that the calculation result updates in all repeats. It shouldn't!
Expected behavior The calculation in the second repeat should update when it becomes relevant (step 3). The calculation in the second repeat should not update when the first repeat becomes relevant (step 4). The calculation in the third repeat should not update when the first repeat becomes relevant (step 4).
Additional context
~~I suspect the issue is with the relative path in the relevant expression.~~ I've already confirmed that the calculations do not run (so it's not an <output> issue)
This TODO seems to describe the issue.
Wow, calculations with a relevant condition and without form controls (i.e. no labels nor hints) are thoroughly broken inside repeats (and probably always have been). I'm not sure if this is fixable without fixing the long-desired placement of #calculated-items in the correct <form>DOM location (i.e. getting rid of the #calculated-items group) where they belong https://github.com/enketo/enketo-transformer/issues/73...
Another solution would be to ignore the relevant expression entirely if something doesn't have a form control (except for pruning when a record is marked as final). This may actually be more XForms compliant. However, the pruning probably doesn't work for the same reason, so this solves the problem of calculating but keeps the problem with pruning.