calculate_here is a datatype in SurveyCTO. I am porting a CTO survey to ODK and would really like to be able to use the same functionality.
1. What is the general goal of the feature?
To allow a variable to be set once but only when that row of the survey is reached.
2. What are some example use cases for this feature?
- Timestamps ahead of each module to track time taken per module.
- Random number generation based on how many times a repeat group has been executed (to randomly pick one of X repeat group instances).
3. What can you contribute to making this feature a reality?
I could beta test.
Does the once() function not cover some of this functionality?
For tracking time, take a look at lightweight timestamping and (although it may be a little more challenging to parse) you can also enable a detailed audit log.
For more details on
once(), here is the relevant section of the docs: https://docs.getodk.org/form-operators-functions/#once
You can get the number of times a repeat group as been executed using
count(), read more here: https://docs.getodk.org/form-operators-functions/#count
Thanks for the response! I will definitely check what you say out.
As for the number of times a repeat group has been executed, I am aware of count(). This is the same as CTO which I have been using for years. What I was hoping for was something where counting the repeat group could be done at a point in the survey so that people couldn't go back and add more.
This is similar to another use case for calculate_here which is that if you want to hand a tablet to a respondent and have them fill confidential things, you can then block backing up and seeing that after they hand it to the FO in CTO. But, without calculate_here, I am unclear if this is possible in ODK.
I realize that you are all answering as volunteers and I I really appreciate you. I myself used to program in Java like more than 10 years ago but now I am just trying to keep my head above water on my current day job while also taking a challenging online course in Data Analytics and managing my two kids, one of whom is autistic. Otherwise, I wouldn't just ask for a feature but offer to help (beyond beta testing).
The fact that you guys respond to questions is amazing. Thank you!
Yes. Some of the functionality is covered as you say but not all. If all of it was covered, I would not be writing here.
Hopefully the ideas @danbjoseph has shared address the lightweight timestamping need! In general, using the
trigger column lets you control when an expression is evaluated: it only evaluates if the question referenced in
trigger changes. Otherwise we don't have a concept of "here" in ODK. Please keep in mind SCTO forked a while ago so their engine and the mental models they build on may be quite different at this point.
We may need more details on your scenario to guide you with the second item. Here are two potentially related tools:
Sorry for the late reply. I appreciate the documentation on trigger.
In my case, I actually didn't need to use trigger in the end I think because I realized that I could use the relevance field in my calculate variable combined with once(). Since all my questions are required, I can check whether the question before where the calculation needs to occur is not null (so the last question in each section that comes before the next section). As soon as the previous question is filled out, then the calculate variable will execute once and mark when they reach the next section for the first time. Reading the documentation, I think I would use trigger for cases where I want it updated the last time not the first time the user reaches a spot in the survey.
As for my second use case where I wanted to prevent people from adding another instance of a repeat group and having that increment the count of number of repeat group instances, I could use the same strategy in that once they get to a certain required question, I can get the count of the repeat group using that same calculate field with relevance set to be not null for the spot where I want it to execute once() and give me the count of the repeat group.
The only case where I would think calculate_here would be better than using calculate with a relevance field or this calculate and trigger feature is in cases where the question you want to trigger on is allowed to be null (so it won't necessarily trigger) but there are very few cases in my surveys where things are allowed to be not required so this isn't an issue for me now anyhow.
So anyhow, thanks again for your answer. I'm glad to learn about trigger and lightweight timestamping. I appreciate the help!