'Trigger' a calculation at the 'end' of a form

Support
1

1. What is the issue? Please be detailed.

I have a calculation that I want to trigger to happen at the very end of a form. My thought was that I could use the metadata field ${end} as a trigger. However, that didn't work.

2. What have you tried to fix the issue?
My next best workaround is to use the last 'required' question in the form to be the trigger for the calculation. But this seems risky as that question could change, or the data collector could fill in answers out of order.

From the documentation, it looks like the metadata fields can't be used for triggers in this way, so I'm looking for a more stable way to trigger the calculation at the end of the form to get around this limitation.

Any ideas?

2

You may be interested in this thread, since its very closely related: Spec proposal: end-geopoint to automatically capture location upon form completion

My thought was that I could use the metadata field ${end} as a trigger. However, that didn't work.

Correct. XLSForm 'triggers' are in actuality xform-value-changed events, whose action is to perform a setvalue operation; see https://getodk.github.io/xforms-spec/#events for the gory details... :slight_smile: This doesn't work for metadata - like ${end} [which in actuality is an XForm timeEnd] because metadata aren't represented by UI controls, so they dont generate an xform-value-changed event when their value happens to be saved.

So, as described previously, what is really required is adding a new event type to the ODK spec - eg odk-instance-finalize - which could then be used to trigger a setvalue (or setgeopoint) action accordingly, eg when the form is finally finalized and no longer editable.

Until then, the best you can do is perhaps have a required question right at the end of your form, eg an XLSForm acknowldege question (https://xlsform.org/en/#question-types) against which you put a trigger to save some calculation result. But, as you've already pointed out, this still doesnt prevent the user from answering this but then going back and changing previous answers, so its far from an ideal solution.

AFAICT there's no foolproof way yet - without an actual odk-instance-finalize (or equivalent) new event type - to accomplish this.

Note, calculations are being re-calculated when you finalize your form; from https://docs.getodk.org/form-logic/#when-expressions-are-evaluated :

When expressions are evaluated

Every expression is constantly re-evaluated as an enumerator progresses through a form. This is an important mental model to have and can explain sometimes unexpected behavior. More specifically, expressions are re-evaluated when:

  • a form is opened
  • the value of any question in the form changes
  • a repeat group is added or deleted
  • a form is saved or finalized

Although, again, when the form is finalized may not necessarily match what you mean by the 'end' of a form [sic]

2 Likes
3

Thanks for this! I provided a link to this thread onto your spec proposal, for some additional context, and gave it a vote. Yes, it's a great idea to have an odk-instance-finalize event type - that's exactly what I was looking for.

For the calculation at the end of my form, I've got a workflow that depends on editing in Enketo, and needs to allow changes to a certain value when the form is open.

  • So the final calculation needs to capture a value at the very end of the first time the form is submitted, but never again.
  • I need to base the calculation on the current value of the variable being 'blank', and then the 'end form' trigger.
  • If I go back to edit in the future, it will never update again.

Not sure if that makes sense. This is why the usual 'this calculation will keep updating, including at the time of submission' doesn't work for me this time around :roll_eyes: