-
Notifications
You must be signed in to change notification settings - Fork 153
Investigate export of submissions pulled from odk dir. #756
Comments
@kkrawczyk123 I think this is happening because the Birds form has a "repeat" field which requires the parents key or instance id to make the necessary linking in the repeats' CSV. All widgets form doesn't have this and so doesn't need to be linked to any other repeat CSV. |
@kkrawczyk123, I've added the instanceID meta field to the Birds form here: Birds.zip Could you use this form and try to reproduce the issue again with this form? |
One of my users has reported unusual export behaviour in v1.16.3 and v1.17. Trying to export to disk seems to halt unexpectedly at n% progress. The GUI does not hang, but the export button de-greys and you can press again. Screenshot attached. |
Here's some output from briefcase.log when this happened. Looks like some problem with encrypted forms
|
Further investigation of this and I think that there could be an issue of compatibility between modern versions of Briefcase and data collected with older versions of aggregate. For instance, I have an old aggregate server still running (v1.4.15 Production) If I export with Briefcase v.1.17.0 I get partial export that halts and an empty CSV file If I rollback to Briefcase v.1.9.0 then I get a complete export with a CSV file NB in this case I got an error in export (not sure if relevant to the problem, so included it in case this is a clue). I wonder if we need a compatibility grid between versions of briefcase and aggregate... |
My first reading of the details you've provided is that modern Briefcase will stall once it gets to a decryption error while processing submissions and that older Briefcase will continue with the export nevertheless. I'll investigate this and we'll probably have to change things so that errored submissions are ignored without halting the export process. |
That's interesting. Presumably if a submission hits one of these So this means that some data that have been submitted will never find their way in to the CSV files; but the warning that this error happened is lost somewhere in the briefcase log. Is there scope to output new logs such as Presumably errors like this are to do with badly formed submissions and can't be fixed. As such it would be helpful to output the i.e. data would look like this
|
I agree with this assessment. Briefcase already creates a We can use this to provide a quick solution to this problem by including them so that you can process them accordingly. It's not the CSV you're asking for, but it can get you there. The way this works is that you would find a log message telling you something like:
|
Hello @ggalmazor, you have been unassigned from this issue because you have not updated this issue or any referenced pull requests for over 15 days. You can reclaim this issue or claim any other issue by commenting Thanks for your contributions, and hope to see you again soon! |
Software versions
Briefcase v1.15, 1.16.x, Java v1.x.x, operating system, Aggregate v1.x.x, Collect v1.x.x...
Problem description
I have noticed that instances of Birds form pulled from odk dir are not exported to csv file. That instances do not have instanceId and it shouldn't be considered as an error but ignored in export. When I removed instanceId from one submission of All widgets form pulled from odk dir, the instance is visible in csv file, just the instanceId is not visible in the csv file.
Steps to reproduce the problem
Export the attached sd content.
Expected behavior
Missing instanceId should not be considered as an error, just like in All widgets case.
Other information
Briefcase 1.15 and 1.16 behave in the same way so it is not regression connected to the release.
attached sd: forms.zip
The text was updated successfully, but these errors were encountered: