If this is becoming a general Web Forms issues thread, the I would like to add [please move to a more appropriate place if that is more useful]:
If using Web Forms to fill in the same form more than once the option 'Fill in form again' is helpful, but it would be really useful if the form would reload to the start of the form rather than the send button at the bottom. Is there a way of setting focus to the first question, for example, on reload?
I realise this is kind of a lazy suggestion, but on a long form it's just minor tedium to scroll back to the top
Hi @ahblake, we have tested the fix on our test servers, and the S3 issue is resolved. S3 blocks Sentry headers. We are in the process of releasing the fixes.
I'm not sure it fits exactly what is in the 'problem' video, and I think it should have been resolved in the version I use.
My ODK Central versions are:
3e9b78f4c7d1636982643585759c3d8a904904e3 (v2026.2.0-1-g3e9b78f)
0000000000000000000000000000000000000000 client (v2026.2.0)
bee93414a2215bd73d7f371113c6640c66d90c95 server (v2026.2.0)
When I click send, the form scrolls to the top before showing the 'fill out again' pop-up. However, when clicked it is active at the send button (no visible scrolling).
So it looks almost like the solution video, but jumps to the bottom of the form.
I have a screen grab but it shows non-public data so I can DM you with it if that helps - unless my version of ODK Central pre-dates the fix.
When completing the form using a public access link it does not give me the option to 'fill out again' even though single submission is set to 'no' - I realise that I can set up a web-user with 'data collector' privilege, but then the respondent(s) need(s) to log in first... Feels slightly counter-intuitive if it is a public access link, so I just refresh the page in order to submit a new form... (my web form is a follow up analysis from fieldwork, so each enumerator might fill in 20 fieldwork forms via Collect (Form A), then 3 or 4 web forms (Form B) - it's easier to use a real keyboard to type the analysis!)
Only adding this here for others to search / see - the various map pin/trace/shape styling fields like marker-color aren't supported yet, I couldn't find it in the roadmap but did locate the relevant issue.
Have hit an error in Webforms that only started occurring in v1.0.1 (also occurs in v.1.0.2), it was performing as expected (and matching Collect) before this. Now it totally crashes out the in progress submission with a load error when the question is answered that affects both a calculation and a read only status in a followup question. In the process of creating an example form I found the 2nd case crashes Webforms all the time, and also causes selections not to appear in Collect.
The attached shows the error. The basic process is there is a list of existing scoped items, selecting one will then preselect the linked item in a followup question and set that question to read only to prevent accidental changes. If the scoped item is picked as 'other' then the followup question is blank and free to be selected by the user.
Example 1: sets read only as ${field}!='other'
Works in Collect as expected
Enketo doesn't apply read only, doesn't crash
WF crashes unless Other is selected
Example 2: sets read only as if(${field}!='other' , 'yes' , 'no')
Collect: if Other selected, no selections appear at all. If anything else selected, selections appear, item prefilled, read only applied.
Enketo doesn't apply read only, doesn't crash
WF crashes for all selections
non read only example - no read only applied, included for completion
works as expected in Collect/Enketo/WF.
The crash message is of the form:
An error occurred while loading this form
Cannot write to readonly field: /data/item_ro1
Assume the crash in the second example is related even when read only is not set, but I'm not sure why the second example also causes no choices at all to appear in Collect!
Probably unrelated, but the docs say to use yes and don't mention also using True but I would have thought that ${field}='x' would resolve to True or False.
Assume the crash in the second example is related even when read only is not set, but I'm not sure why the second example also causes no choices at all to appear in Collect!
Probably unrelated, but the docs say to use yes and don't mention also using True but I would have thought that ${field}='x' would resolve to True or False.
The yes works in the read_only column because pyxform converts it to true() when the form is converted (xlsform to xml). But inside an expression it's just text (in XPath any non-empty text counts as true), so if(${scope_ro2} != 'Other', 'yes', 'no') makes the field readonly in both cases. That's why example 2 always crashes. You'd need true()/false() instead, or just drop the if() and use ${scope_ro2} != 'Other' directly. As for Collect, I haven't checked the latest source code, but I remember it doesn't render the choices because the field is always readonly.
Ahh ok - so for Collect, if read only and a value is calculated, the choices appear and one is selected. if "not" read only (but actually it's evaulating to read only) and with no value calculated, no choices appear. That clears that up.
And so if I needed a more complicated read only expression then it has to be written like if((${something} = '2' and ${scope_ro2} != 'Other'), true(), false()) ?
I have a form that I went to switch from Enketo to WF and on load received the following error
An error occurred while loading this form
The function 'distance' received a value that does not represent GPS coordinates
The field with the function had a calculation as round(distance(${line_trace}),2)
Adding a trigger to the field as ${line_trace} allowed the form to load, but I guess it would be preferable if the form didn't fail on load if distance evaluates on a blank field. Not sure if this is already resolved with other changes for v1.0.3
@ahblake Thanks for letting us know! No, that hasn't been worked on in 1.0.3. There's a similar error in Collect but it only happens for invalid data (eg: "foo"), not for empty values. I'm assuming that because this is happening on load the ${line_trace} is blank?
yep, that's the cause. I fixed that form by adding a trigger so the calculation wouldn't try to evaluate on load, only when there is a valid geotrace available.
@ahblake Despite my best efforts, the distance bug didn't quite make it in to 1.0.3. The fix ended up a bit more complicated than I'd hoped, and we decided not to risk breaking something else by rushing it out. It's bound to be in the next release though!
