Hi Amar and lobo,
Sorry for the delay in responding to this, and thanks lobo for bringing this back up because we agree that it is important to address. The issue here involves our decision last year to start to support multi-versioned forms (aka. redeployment). The issue of how to edit submissions to previous versions is a complicated one because of kobocat’s structure as an ODK/OpenRosa endpoint, and how enketo is paired with kobocat.
The most direct way to edit submissions to old versions of forms is to redeploy that particular version, which would make submissions to that version function normally. I understand this is not acceptable for most users. The most actionable solution that I see being built, however, would allow the user to revert the deployment back to a previous version of the form (from a list of versions). This would be a clunky solution.
Beyond that option, another path could be to create an endpoint in kobocat that simulates a deployment of an old version, directs Enketo to that endpoint, and opens the submission in that context. This could take a bit of work on the kobocat end, and involves a direction that we do not currently have in our sights. It’s possible, though, that I am overestimating the work this would take on the kobocat end. In our experience, kobocat modifications are very hard to estimate, which is why we are transitioning the functionality piece-by-piece over to the kobo-api (kpi) project.
And finally, a third solution that I believe is feasible, is to create a sort of “raw edit” view, that allows the submission to be opened up in a JSON editor and allows modifications to the data in a way that does not enforce logic of the form (skip logic and validation). This would probably involve creating a json-schema from the corresponding form version, and then building a view that uses a json-schema-based tool to edit and submit any changes.
None of these are road-mapped for our team in the next couple months, and regrettably this represents a very valid use case of the experimental redeployment feature that we didn’t prepare for ahead of time. Right now, we are working hard to ensure that exports of multi-versioned forms are meaningful and include all the data in all cases, so that we can finally combine “legacy” and the new formpack-based exports into one.
I’d be happy to talk with someone in more detail if they would like to work towards one of these solutions in a way that we can incorporate into the tool.
On Monday, April 10, 2017 at 5:40:28 PM UTC+1, Donald Lobo wrote:
hey kobo folks:
any more news on this. We’d be happy to help debug / fix the issue if you’ll can guide us on this.
a response would be highly appreciated
On Monday, March 27, 2017 at 12:14:57 AM UTC-7, Amar Kamthe wrote:
To reproduce this issue follow below steps,
- Create and deploy a form with any number of fields.
- Fill atleast one entry using kobocollect app or Enter data in browser links.
- Update the form say by adding new field and redeploy the same.
- Now try to edit the #2 entry. This will give you message “error trying to parse xml”.
On Monday, March 27, 2017 at 12:36:46 PM UTC+5:30, Amar Kamthe wrote:
Kobo Team :
Any updates on this issue. As it still persist in the latest kobo-docker update.
We are not able to update the records.
On Monday, February 6, 2017 at 6:30:39 PM UTC+5:30, Amar Kamthe wrote:
Hello Kobo Team,
I am using kobo-docker using local setup. I have created one survey form and collected data. Today I updated the survey form by adding couple of questions. After redeploying the survey, I am not able to edit the records that were previously collected. Below is the screenshot for the same.
Any support for this?