I want to set text fields (names) in a repeated group to blank ('') once the interviewer is done with the questionnaire, as the text field is just a help for the interviewer during the interview; I don't want the data. So at the end of the questionnaire I have added a tick box called 'delete' hoping to use it as a trigger to enter the default.
This worked outside the repeat group. But inside it, I get into trouble:
So I've done what works everywhere:
In the name question in the repeat group I've entered '' under calculation and ${delete} under trigger. I get no errors when deploying the form, but when arriving to the delete question I get an error:
XPath evaluation: type mismatch
You are trying to target a repeated field. Currently you may only target a field in a specific repeat instance.
Xpath nodeset has more than one node [" + reference + "].
This seems like a strange limitation; is there a workaround?
For anonymization, we used another approach, also inside repeats:
The name field(s) have a relevant clause: ${SetAnonym} != "OK":
(based on acknowledge type SetAnonym variable, required, at the end).
An advantage might be that only on save the name fields are emptied. So an erroneous tick could still be corrected before.
But your trigger example needs further examination, e.g. by @LN or @Xiphware, please.
I really like this approach! I agree that the fact that it's reversible up until a form is finalized is a nice aspect of the solution. Let's add this technique to docs: https://github.com/getodk/docs/issues/1935
I agree it's unexpected but unfortunately it's not an easy limitation to remove. Hopefully the relevance approach will work for you.
So there is some weird behaviour in Enketo that seems related (like updating only the first instance), but the trigger is outside the repeat group. I am not really using Enketo so I wouldn't know more tb..
For anonymization, we used another approach, also inside repeats:
The name field(s) have a relevant clause: ${SetAnonym} != "OK":
(based on acknowledge type SetAnonym variable, required, at the end).
I agree it's unexpected but unfortunately it's not an easy limitation to remove. Hopefully the relevance approach will work for you.
Yeah, I figered as much.
I agree that the the relevant solution should be added to the docs. In most of the household surveys I have seen, researchers ask names of household members without ever actually needing them in the final data, it should be standard practice to do something like this. However, I had tried looking for a way to do it, and only found people saying it's just not possible.