This probably needs to be brought to attention of @martijnr
We cannot clean/edit submitted data, based on this bug. Maybe there is at least advice for a workaround, like using a full path reference?
I think this may have been an old pyxform bug (even though it doesn’t occur in Collect) or an old Enketo bug. It doesn’t seem to occur when using the latest published version of both (I haven’t tested old versions).
If it can be reproduced when using the latest version of both, please file an issue in enketo-core (KoBoToolbox QA, @Kal_Lam ).
That’s what we used (see above). Also, for the example provided.
Do you have an idea for a workaround. As we are blocked cleaning survey data (on server level).
That’s what we used
No, I don’t think so. Professional adopters of the Enketo and pyxform tools, such as KoBoToolbox, are always a little behind and should be because they do their own QA.
Not sure if pyxform version is visible anywhere but you can check the Enketo (Express) version by going to the root Enketo url, e.g. https://ee.humanitarianresponse.info/.
The Enketo Express releases are published here: enketo-express/CHANGELOG.md at master · enketo/enketo-express · GitHub
Hello @Kal_Lam. @martijnr,
Thanks for the answer and the links. We are normal KoBoToolbox and ODK users, using the latest system releases as they are available to the related public. And we try to report problems and errors based on this, here in the community.
As far as we can see - without digging into GitHub with about 30 source elements, sorry - the Enketo version available in KoBo is at the moment
This is the same as on the root Enketo url, e.g. https://ee.humanitarianresponse.info/ .
This seems to be two versions behind master Enketo
We cannot see in the change look, if the bug was solved in one of the new updates.
I am sorry, I didn’t well understood: Did Martin test this example already without problems? (2.6,1? 2.6.0?)
The support demand is, please:
- We found a bug in using Enketo from KoBoToolbox. See example.
- We reported it here, incl. a reproducible example (28-01-20)
- We had to stop (time-critical) data cleaning of a survey, based on this problem
- We are looking for a solution or at least a workaround, please.
Let us understand, please, who should do what now to advance?
Thanks in advance.
Any news on this, please?
A useful piece of information here is that previewing these forms works just fine; it’s not until they’re deployed and opened for data collection that the problem appears. This points to an issue with the way KoBoCAT is using pyxform.
I tried upgrading Enketo to 2.6.1 while leaving KPI and KoBoCAT unchanged, and the behavior is identical: previewing works fine, but a form opened for data collection shows the errors.
Hi @martijnr, I’m sorry to report that there’s still a problem with this form when testing on a freshly-installed ODK Central instance:
As I mentioned in my last post, this is an odd one because:
It’s only the act of submitting that triggers the error.
I should note that Central is shipping Enketo 2.5.6 currently, but seeing as XML-generation discrepancies are now out of the equation—and I’ve already tested 2.6.1 with KoBoToolbox—I’m not attempting to upgrade Central’s Enketo at the moment.
My Central instance is running
getodk/pyxform-http:v1.3.4, which uses pyxform 1.3.4. I’ll include the XML below, which was generated from
Bug Edit01.xlsx in the first post.
<?xml version="1.0"?> <h:html xmlns="http://www.w3.org/2002/xforms" xmlns:ev="http://www.w3.org/2001/xml-events" xmlns:h="http://www.w3.org/1999/xhtml" xmlns:jr="http://openrosa.org/javarosa" xmlns:odk="http://www.opendatakit.org/xforms" xmlns:orx="http://openrosa.org/xforms" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <h:head> <h:title>Bug Edit01</h:title> <model odk:xforms-version="1.0.0"> <itext> <translation default="true()" lang="English (en)"> <text id="/data/StopInterview:label"> <value>StopInterview</value> </text> <text id="/data/HHMTotal:label"> <value>How many persons are usually living in this household, in TOTAL?</value> </text> <text id="/data/IV_RP:label"> <value>INDIV</value> </text> <text id="/data/IV_RP/WorkPayment:label"> <value>What was the value of NAME's last PAYMENT (income) for work activities, in cash and kind? Total In USD</value> </text> <text id="/data/IV_RP/DaysPayment:label"> <value>How many DAYS in total did NAME work for this payment?</value> </text> <text id="/data/IV_RP/WorkPaymentPerDay:label"> <value>WorkPaymentPerDay</value> </text> <text id="/data/IV_RP/WorkPaymentChk:label"> <value>CHECK : NAME earned about <output value=" ../WorkPaymentPerDay "/> USD per day of work? Is this correct?</value> </text> </translation> </itext> <instance> <data id="Bug_Edit01" version="2021012805"> <StopInterview/> <HHMTotal/> <IV_RP_count/> <IV_RP jr:template=""> <WorkPayment/> <DaysPayment/> <WorkPaymentPerDay/> <WorkPaymentChk/> </IV_RP> <IV_RP> <WorkPayment/> <DaysPayment/> <WorkPaymentPerDay/> <WorkPaymentChk/> </IV_RP> <meta> <instanceID/> </meta> </data> </instance> <bind nodeset="/data/StopInterview" type="int"/> <bind nodeset="/data/HHMTotal" relevant=" /data/StopInterview = 2" required="true()" type="int"/> <bind calculate=" /data/HHMTotal " nodeset="/data/IV_RP_count" readonly="true()" type="string"/> <bind nodeset="/data/IV_RP" relevant=" /data/HHMTotal > 0 and /data/StopInterview = 2"/> <bind nodeset="/data/IV_RP/WorkPayment" required="true()" type="int"/> <bind nodeset="/data/IV_RP/DaysPayment" required="true()" type="int"/> <bind calculate="round( ../WorkPayment div ../DaysPayment , 0)" nodeset="/data/IV_RP/WorkPaymentPerDay" relevant=" ../DaysPayment > 0" type="string"/> <bind nodeset="/data/IV_RP/WorkPaymentChk" required="true()" type="string"/> <bind jr:preload="uid" nodeset="/data/meta/instanceID" readonly="true()" type="string"/> </model> </h:head> <h:body> <input ref="/data/StopInterview"> <label ref="jr:itext('/data/StopInterview:label')"/> </input> <input ref="/data/HHMTotal"> <label ref="jr:itext('/data/HHMTotal:label')"/> </input> <group ref="/data/IV_RP"> <label ref="jr:itext('/data/IV_RP:label')"/> <repeat jr:count=" /data/IV_RP_count " nodeset="/data/IV_RP"> <input ref="/data/IV_RP/WorkPayment"> <label ref="jr:itext('/data/IV_RP/WorkPayment:label')"/> </input> <input ref="/data/IV_RP/DaysPayment"> <label ref="jr:itext('/data/IV_RP/DaysPayment:label')"/> </input> <trigger ref="/data/IV_RP/WorkPaymentChk"> <label ref="jr:itext('/data/IV_RP/WorkPaymentChk:label')"/> </trigger> </repeat> </group> </h:body> </h:html>
@Josh, there are a few “context node” issues in enketo-core, but I’m not sure if they’re related: Issues · enketo/enketo-core · GitHub.
Could you please have a look and file a new issue if needed? Discourse ought to let you see the Markdown of my previous post, which you could more-or-less paste into GitHub if a new issue ends up being the way to go. Thank you.
Hello @Josh, @jnm , @Kal_Lam
Do we have any news on this, please?. The bug is still there, we tested again today, after the latest release. Is there a github entry to follow up, please?
Thanks and regards
No. Please observe that the latest release did not update Enketo.
Still no but we’ll respond here when we have some progress to share.
Hi @wroos, sorry for the delay. Here is the GitHub issue that you can track. Note that there is no guaranteed timeline for a fix so please be patient.
if you have a calculate widget that adds together two previous responses, you cannot use relevant to skip in the case of missing values. (Missing values will cause an error.)
I took your Bug XLSForms above and after applying their suggestion it seems to work as you intended it — can you confirm if this is the case?
Really good finding, which also explains why the same worked as integer type.
If I understand well, it means that ALL calculation types are always “fired”, even in an empty repeat (count 0) or a non-relevant group. So, a relevant clause together with a calculation type NEVER makes sense. Could you confirm, please?
To add a hint/link in KoBo calculation support article might help the community.
Hi @wroos, yes that does seem to explain why it worked with
That’s my understanding from the above warning and the experience I had when looking into this before — I was also under the impression that it may have been a bug but I guess it was designed that way for a reason.
I will update the support article
I adapted the tags of the thread now (no more “bug”).