Hi @Kal_Lam
For age the only constraint should be if the enumerator enters 0 or 100 all other age values are allowed. For “Please confirm that all three criteria match the call list before proceeding” if the enumerator selects Yes it should allow them to proceed. If they select No the flag should appear. For “Was the appointment scehduled?” if the enumertor selects Yes they should be allowed proceed IF they answered No to all previous screening questions.
Best wishes
Catherine
Allow an entry if the value is between 0 to 100.
So basically, you wish to have a positive answer for this question from all your respondents? If no, what do you intend to do after flagging a message?
I get you till yes. So what do you mean by saying if no to all previous screening questions?
“Please confirm that all three criteria match the call list before proceeding” If the enumerator selects No then the interview should be stopped because potentially they are speaking to the wrong person. They should not submit this to the kobo toolbox server until they can select Yes to this question.
“Was the appointment scehduled?” The answer to this question depends on the answer to 4 preceeing ‘screening’ questions:
“Are you suffering from a fever?”
“Are any of your family or household members suffering from a fever or suspected fever due to COVID?”
“Is anyone in you family or household a confirmed COVID patient?”
“Have you taken care of anyone who is a suspected or confirmed case for COVID?”
If the answer to any of these questions is Yes then the answer to “Was the appointment scehduled?” can only be No.
This answer has a few clauses in it, so maybe it is this that is causing the issue but “Was the appointment scehduled?” Can only be Yes IF the 4 screening questions are No AND IF “Are you happy to continue with scheduling your appointment?” =Yes AND IF participant_status=Answered
Best wishes
Catherine
So what you are basically trying to do here (for the validation) is:
Should be Yes
Still not sure
Still not sure
Should be Yes
Regarding your appointment scheduled:
All or is it any of the screening questions that needs to be Yes in-order to activate this question?
I don’t think I have explained the issue well. The constraints all work if the call attempt is attempt 1 and the participant_status is answered.
However If the attempt=1 AND participant_Status Not Equal 1 then the form is saved on enumerator’s device. Their SOP states to re-attempt this participant later (that day or tomorrow).
It is on the next attempt when the errors start to appear. So attempt=1 in the saved form however when the enumerator goes to make a 2nd attempt they open their saved form and edit it. They change attempt=1 to attempt=2 then they also change participant_status from e.g. No answer to Answered. They they proceed with the validation of name, age and gender. It is only on this type of scenario that the constraints do not work.
Hello,
Can you make sure that
Can you reproduce the erroneous situation with Preview of the new form version (Enketo on the server)?
Hi @wroos
Yes I Have tested this on the app i have on my own android phone, I still get the issues. I recorded a video of me inputting data with the errors but I can see mp4 file types cannot be uploaded. Is there any method to share this with you in a private message?
Regards
Catherine
Hello,
Would you mind to use the search function of the form, with token “send private message”?
But you may better send to @Kal_Lam, please.
I cannot share my mp4 file which records my phone screen as I entered data into the kobo collect app. I think it would explain the issue we are facing better than my messages are doing.
In any case the xls form that I uploaded in this thread has all the quesitons and the constraints we used. These work when the enumerator enters data for the first time and if the participant_status is answered.
They don’t work when the enumerator has saved the form and then edits it.
Why would editing the variables attempt and participant_status cause issues with the constraints we have coded?
Regards
Catherine
Hi @cp622
On the first issue
I believe there is an issue with your constraint
(.=‘0’ and ${validation_name}=‘0’) or (.=‘1’ and ${validation_name}=‘1’) for question validation.
What you have defined is that the validation will only accept a no i.e. 0 if validation_name is a no and it will only accept a 1 i.e. yes if validation name is 1.
The error you displayed in your very first message 1 of 11 hints to the fact that the validation_name was no (0) and yet, the choice being made at validation was yes i.e. 1
Action; Kindly recheck your logic ensure that the change on validation_name is made prior to changing validation.
I would indicate the logic as .=${validation_name} if the above is what is intended
On the second age issue: You indicate that you want to allow an age of between 0 to 100 however your logic states .<=100 and .>10 I suggest you indicate .<=100 and it should work fine. Does this also fail on the second visits but works on the first visit 
On the third issue
I am a bit confused by what your constraint is doing
(.=‘1’ and (${screening}= ‘0’) and ${screening2}=‘0’ and ${screening3}=‘0’ and ${screening4}=‘0’ and ${continue}=‘1’ and ${participant_status}=‘1’) or (.=‘0’ and (${screening}= ‘1’ or ${screening2}=‘1’ or ${screening3}=‘1’ or ${screening4}=‘1’ or ${continue}=‘0’ or ${participant_status}=‘2’ or ${participant_status}=‘3’ or ${participant_status}=‘4’ or ${participant_status}=‘5’ or ${participant_status}=‘6’ or ${availability}=‘0’))
I believe your form would benefit from a redesign where you compute the value that is needed in the question ${Schedule} since the constraints indicated that the value can actually be predicted by the previous responses.
Stephane
Hi Catherine,
Thanks for sharing your form. I am working on a project at the moment which is providing free specialised information assistance to covid related projects.
While the error didnt replicate in my test, the reason for such an error would be a logical inconsistency caused by the fact that changing the response to an earlier question means that information stored in a later questions is “impossible” and therefore constraints are triggered which are not part of the question currently on screen. As Stephen mentions your final constraint really functions more as a reminder note to the enumerator than a traditional constraint so maybe there is an opportunity there too.
Can I ask why you have chosen this flow where the enumerator re-opens an existing form? Is it mostly to avoid having to re-enter the staff and study IDs?
If so I would be happy to discuss alternatives which could simplify the flow of data entry and avoid losing the record of data related for failed calls or incorrectly made appointments as that could be necessary data for you to be able to show later. For example if it would prove that the majority of possible infectious cases did not provide blood samples which right now cannot be demonstrated in the data.
Do please let me know if you would like to discuss ways to solve these issues without creating extra work for enumerators.
Noel
Dear @stephanealoo and @NoelCartONG
Many thanks for both of your responses,
Yes It seems it is the overwriting of data that is causing this issue. The constraints we have maybe lengthy but I am not sure there is anything wrong with the logic in them, however we may look into changing them.
We decided that it would be too risky to give each enumerator edit permissions on a given studyID after it has been submitted to the server. So instead our protocol states they should save the attempt on their device (within the kobo app) until they have received a successful answer from the respondent OR until they reach a maximum number of attempts (max=5) at different times and days. If we didn’t take this approach we would end up with multiple entries for the same studyID. Also I have a reminder system set up outside of kobo to remind the enumerators of all outstanding interviews. They can compare my list against their saved forms and if there are any outstanding they can finalise the attempts or if they are not in their saved forms they need to start the process.
On other apps my colleague designed she added an attempt date, time and participant status for all 5 attempts, however for this particular app she just added one attempt date, time and participant status. We thought this was the issue however I could not explain why. I think @NoelCartONG explanation makes sense for our particular issue because it only happens after editing a saved form, rather than on first entry when everything runs smoothly (i.e. the respondent answeres straight away). This is also why I am less worried about our constraints being clunky
I would be very interested in discussing alternatives to simplfy data entry.
Regards
Catherine
Hi Catherine,
I understand completely your logic for not giving enumerator access to edit via the website and think you are completely correct there.
There are two main types of solution i can think of:
1. Turn “appointment_schedule” group into a repeat group so that the questions coming afterwards are per call rather than per household/person
2. Use a system where information on every call (even failed calls) is sent to the server. This would fix your error and also simplify the process. Of course the downside is having to re-enter the IDs and entering IDs can always create problems with data entry. I would suggest a system including the use of barcodes so that these number do not need to be typed even the first time and probably also to include Device IDs. This would be a bigger change but bring additional benefits.
Either way I would suggest to change the structure somewhat to replace the final question as that constraint is going to cause you problems when it comes to analysis. A calculation and note would work better there and would be recommended as a more important change.
Noel
Thanks @NoelCartONG for these suggestions,
Unfortunately while barcodes would be great, if I understand you suggestion properly it would mean having a barcode scanner for each enumerator. This may be possible with QR codes or something like that however I am not skill in this area and would probably not be able to implement it.
The issue with submitting each failed attempt to the server is that there would be duplicateIDs and I would need to get into the habit of just taking the latest submission, which is fine in theory but since the start of our study in June we have had hundreds of duplicates caused by the wrong ID being entered. So I am afraid that I would miss these if I cannot check for duplicates.
Your point on appointment_schedule group into a repeat group I think is one we could explore, thank you
I will post into this thread again if we get a solution 
Catherine
Hi,
Thanks for offering to share the solution afterwards as I am sure it will help others with a similiar error.
Barcode scanners are not usually needed if the mobile devices have working cameras. If you have hundreds of accidental duplicates with many due to typing errors, it would help reduce that. However as I don’t know your context well, there could well be other practical barriers to using bar codes that I am unaware of.
I hope the repeat group idea will solve the issue of the errors. Please note that it will change the structure of your data export. If you have any questions about my comment for the “scheduled” constraint do let me know as that would be much more value in changing that final question than fixing the original error.
Noel
Dear @Kal_Lam @stephanealoo @wroos @NoelCartONG
Many thanks for all you advice on this topic thus far. @NoelCartONG was able to view the screen recorder video of my attempts to the kobo collect app. He could see where the errors were flagging. He uploaded the form I have posted in this thread and test it using firstly the kobo collect app, then he uninstalled this app and installed ODK collect. In ODK collect there are no issue with the app. It works how we intended.
I have completed the same steps as Noel by uninstalling the kobo collect app and can verify his results.
In this case it appears to be an issue with the kobo collect app.
Are there any next steps that can be taken from your side?
Best wishes
Catherine
Hi all,
I can confirm the information provided by Catherine above in addition to the following information from my investigation:
I attach a fresh copy of the form with some additiona constraint message which help demonstrate the issue.
Scheduling_v5_Bauniabadh.xlsx (25.1 KB)
Steps followed to reproduce error in Kobo Collect:
It seems that its probably not worth spending a long time on a detailed investigation of the issue as it doesn’t seem to have come from any adaptations made specifically for the Kobo version of the application. Taking a fresh fork from ODK Collect v1.28.4 should fix the problem.
Noel
Thank you @NoelCartONG @cp622 for flagging the issue that it’s time for KoBoToolbox to update the KoBoCollect android app to solve the issue.
Hi @cp622,
Kindly please be informed that KoBoCollect v1.29.3 has been rolled out and you should soon receive the updates in your device. This release should solve the issue you have reported earlier.
