Dear ODK Friends,
Is it not possible to take a value of any question as a dynamic default value in to an intended question inside repeat group?
Sample form here.
Thanks in advance.
Regards,
Raj
Hi @aurdipas,
Thanks for your support.
However, when the Current_Job is inside a group (outside repeat) and the Previous_Job is also in a group inside a repeat, the result will not be desirable using once() function.
Can you please look again at this?
Thanks.
Raj
Dear @Raj_Pravat
what is the problem exactly.
For me it works exactly the same
Default to Repeat.xlsx (8.9 KB)
Thanks, @aurdipas,
The problem is, when used with field-list appearance in those groups outside and inside repeat group, default Job in the first repeat is not desirable, subsequent repeats are okay. That means, say, the Job is 'Office Assistant', the default value of this inside the group (History) of the repeat group is not the same as its initial value specially in the case of when there are more than one word in the Job.
Hope you get my point. I am using ODK collect with Central.
Raj
still I don't see the problem.
Tested the attached form and it seems fine for me.
Default to Repeat.xlsx (9.1 KB)
Dear @aurdipas,
Many thanks for your attention.
However I am getting results as attached screenshot of Collect. I am on with latest beta version of Collect -
https://github.com/getodk/collect/releases/tag/v2021.2-beta.0
Regards,
Raj
It looks like a bug from collect.
@Grzesiek2010 are you aware of it?
In the repeat instead of taking the value from the outside repeat it takes only the first letter.
The latest xls form in the post can be used to test it.
PS: it works in Enketo.
I tested with ODK Central 1.2.1 and Collect 1.30.1
1 Like
Yes it seems like a bug but rather in Javarosa not Collect so I reported it here https://github.com/getodk/javarosa/issues/636
I think removing that once() function fixes the issue and it's not crucial so it should help right?
This is the expected behavior because Current_Job is in a field list. once is a very odd function and actually means "if the current field's value is not empty, compute the given expression." Text fields in field lists trigger recomputation on every keystroke to enable things like progressive search within a field list. In this case, as soon as the first character of Current_Job is entered, the form recomputes and once(${Current_Job}) sets the value of Job_Default. Then when another character is entered into Current_Job, there already is a value in Job_Default so it is not recomputed.
The easiest change to get the behavior you seem to want is to remove Current_Job from a field list.
It's not really clear to me what the form intent is. If the desire is to get a dynamic default, then yes, once is required. In that case, the Previous_Job follow-up question may not make sense. once is not the recommended way to do dynamic defaults (see docs on the recommended strategy) but in this case it's the only option because we don't support this kind of dynamic default from outside a repeat to inside (issue).
From what I understand of the intent, I would probably do something like ask a yes/no question like "Did you have a job before ${Current_Job}" and use that to decide whether or not to prompt for job history but maybe that's not right for the actual context.
Hi @LN,
Thanks for taking up this, and for your suggestions. Also thanks to @aurdipas and @Grzesiek2010.
The appearance 'field-list' is very important to help understand the enumerator the questions ahead, and set a good rapport building idea during the inteview with the respondent. So is the case also with my questionnaire approach.
The intent of the part of the questionnaire is to record job transfer details of a public company having nearly 15,000 staffs and huge transfer history of its staffs within the company even in a single year. The staffs may have transfer history with different job title (however the levels and position of job are mostly the same). The enumerator first ask the basic questions outside repeat, and then records the history of his/her transfers. Asking again "Is your job title with your previous transfer same as current job title?" is not a right approach, I suppose.
Hope I am able to make my point clear to you.
Kind regards,
Raj