The problem
At the end of a questionnaire, the user is presented with the following screen:
(Please refer to “Image 1” in the attached screen shot)
The screen provides the user with two options - either saving the form as “finalized” or saving the form as “incomplete”. We would like to force the user to finalize their submission, i.e. we do not want them to have the option of saving their submission as ‘incomplete’. How can we achieve that?
What we have tried
We thought that we could perhaps take a short-cut by simply not displaying the “Incomplete” button to user. We dug through the files in app-designer/app/system/ and discovered a file named ‘finalize.handlebars’ (in app-designer/app/system/survey/templates) which seemed to be the template for that screen (it is in fact the file referred to by app-designer/app/system/survey/js/prompts.js). We edited the file and removed the code that renders the “Incomplete” button, leaving the file as:
(Please refer to “Image 2” in the attached screen shot)
We ran the simple “grunt” command again to push the changes to the device, but it seemed to have no effect - at the end of the questionnaire the “Incomplete” button was still there, next to the “Finalize” button. The screen looked exactly the same as before.
Furthermore, we are well aware that, even if we did succeed in hiding the “Incomplete” button from the screen above, the user would still be able to save an incomplete submission via methods two and three as described at ODK-X Survey — ODK-X Docs
It would be ideal if we could prevent the latter two cases as well, but it is not as important to us as preventing an incomplete submission via the “End” screen.
You could ad the following to the ‘initial’-worksheet in your survey.
I found this in one of the example forms and I’m using this method myself. It seems to work fine.
clause
type
comments
do section survey
goto _finalize
skips the finalize screen where the user chooses to save as incomplete or finalized and instead saves as finalized
Hi Andreas
Thank you for your quick reply
I’ve tried that now, but it then gives me problems with required values. Please find a shortened copy of our XLSX form attached. It now seems as if it is trying to finalize right at the very start of the questionnaire, without even storing the answer of the very first question.
I’m in no way an expert and don’t know why you get this problem. I haven’t gotten this error in my forms, and I also make use of different required values.
However I get the same error if I remove “goto _finalize” from the initial-sheet. Maybe your problem is elsewhere?
So could you explain a bit more about the steps that caused the problem here? Is it that you just opened the first screen and got this error, or did you try to save as incomplete and have this problem?
Thank you, @Andreas. I tested it now without the “goto _finalize” on the “initial sheet” and I see what you mean. It seems like it’s the “do section survey” clause that is actually causing the problem… When I remove that too (i.e. having an empty “initial” sheet) the questionnaire works like it used to (still without the automatic finalization, though).
Use the XLSX Converter that comes with the app-designer (ODK 2.1.0) to convert the example.xlsx spreadsheet to JSON and save it to file.
Run grunt adbpush-default-app to push the questionnaire to your mobile device.
Open ODK Survey on your mobile device, go to “Sync” and click “Reset App Server”.
Once synced, click on the questionnaire to start a new submission.
And at this point things become strange. Instead of showing me the usual screen (screen shot 1 attached) it jumps directly to the first question (screen shot 2 attached). Then, regardless of what option I choose as my answer at question 1, it presents me with the error (the screen shot that I attached to my first reply to @Andreas) when I try to continue to the next question - as if I didn’t answer the question at all. And that leaves me stuck.
Thanks for the additional detail especially in #4! I can at least tell you one thing that is going on. It seems like the goto _finalize also skips the add instance screen (see: Home · AbalobiSA/Abalobi_docs Wiki · GitHub) so that’s why you are suddenly starting “in” the survey.
One difference looking at your structure versus the examples I have is that you have additional sections beyond survey. I am wondering if that is causing some navigation confusion – particularly since everything else in the form, it sounds like, worked fine before adding this.
Have you tried experimenting with putting goto _finalize clause in a different spot within the survey to see if it helps address that, e.g. within the survey sheet? Experimenting with its location to see what behavior results is what I would try next.
If I put the “goto _finalize” statement at the end of the “survey” sheet, I get the same error.
Furthermore, I tried searching for some information on the “_finalize” tag itself in the ODK-X documentation, but I didn’t find anything useful (maybe I just missed it). In fact, I half expected it to be discussed under “operations” in this article Survey formDef.json Structure — ODK-X Docs, seeing that it is somewhat related to the “validate” and “save_and_terminate” operations, but alas. I am wondering now if I should not perhaps try to construct a work-around using the latter two operations, rather than the “_finalize” thing
indeed! So I am not as familiar with this part of the code but am going to tag in here @linl33 who hopefully can offer some insight on how to force users to save only as finalized, one way or the other…
I believe the problem is caused by the fact there is no currentInstanceId. When you manually create an initialization you change the workflow. Since your workflow does not have the “instances” type the else clause in the example in the documentation the screen is skipped. Survey’s rendering engine does not know what the currentInstanceId is (which is the unique identifier used to write to the database). You always need a unique identifier.
Not having the instances screen appear can be handy as you can specify the instance ID when opening the form (basically choosing for the user). However if you do not programmatically specify the an instance ID and you change the workflow so the instance chooser screen does not appear, the system does not know what the instance ID which can cause weird behavior.
SUCCESS! Thank you. It seems like that was indeed the problem.
Just for future reference, this is what the final version of my “initial” sheet looks like: