Uploading a new version of an already submitted response.
What are the most likely user stories for how and when this would be used by someone on your team?
A volunteer goes through a slums making surveys and realizes that he or she needs to access an existing case (not uploaded by her) and generate a new updated version of it.
Can you sketch out graphically how you think this should look/work in practice?
How useful would this feature be to other users or organizations?
I think it would have great value for organizations do recurring survey work. Many organizations want to know how cases evolved through time for research or operative reasons.
This feature helps to extend kobo in that direction, supporting teams that make follow up work.
What can you contribute to making this feature a reality?
TECHO could help with funding, we could consider fund it by ourselves -to cover developers and related expenses depending on the whole cost- or by applying together to international funding (like this for instance)
A complete user story with a user case can be found here
Great suggestion, @marcos_techo⌠This is a great feature thatâs been requested by many others. To be sure, updating records is already possible (if you have edit rights) but requires Internet.
In practice this could be using the following workflow:
Enumerator collects data, submits it to the server, e.g. a household registration at the beginning of a relief program
Several weeks later, the survey administrator wants to conduct an update of the form, enabling âallow record updatesâ in the backend.
The same or a different enumerator returns to household several weeks later. Before going to the field, she synchronizes her device with the server, which pulls a copy of all records and stores them offline.
She opens Collect, clicks on âUpdate recordsâ, searches for the household in question (e.g. typing in family name or household ID), and clicks on the correct record.
She is able to scroll through the questionnaire, checking if all registration items are still accurate
If anything has changed (or was incorrect), she makes changes to the data and saves the record.
The submission is queued as usual to be submitted upon reconnecting the device to the Internet.
When the program admin checks the dataset, she sees the updated record in the database.
Clicking on âsee submission historyâ, she can see the previous versions, including when and by whom they were submitted, and which fields were changed (highlighted through different color background).
Nice to have: Instead of each interviewer downloading all records, this could be optionally limited to records where the user has the permission to edit data (row-level permissions are being added in KoBoToolbox in the coming months).
This feature is related but not quite the same as the use case of linking data from different projects (e.g. a base registration dataset thatâs included in different follow-up forms each month). This can be done with external csv datasets but could be made a lot easier.
Any other use cases from other users that should be considered?
Hi, this would be great advance for users and organizations that what to know how cases evolved, like Marcos said before. Also, it would make easier for users give the possibility to trace back submitted record according to some ID chosen.
Features usefull that can be added in my opinion:
Filters (could be State, department or city; Document/Passport some ID that belongs to single person) that allows to trace records from the server (like Tino said).
Instead of loading all fields completed in previous record, I imagine it could bring fields only called, detailed in another form with same name code, or selected before in admin page.
âClicking on âsee submission historyâ, she can see the previous versions, including when and by whom they were submitted, and which fields were changed (highlighted through different color background).â I like this. Only suggestion from myself, is to highlight the fields changed and show in a messagebox or a popup when place the mouse over the label, the old-field value
Is essential to allow search for previous record in kobocollect app and in browser form.
Getting previous records and save them in the device or in the memory browser, could be essential for using later on the field, and for changing info that have to be updated.
Another thing that came to my mind recently is related to the download of records.
It could be useful to allow a single person select a group of records, and generate a parcial download, with a generic link, allowing users not logged to download the selected records. This way will suply simple ways to download records for people that doesnât know Koboâs feature for admin, and 'll make it easier for them
Basically, itâs for prefilling (default) form values from previously saved forms. Although itâs not âupdatingâ existing forms per se, by prefilling the contents of a new form with an earlier one, you could then resubmit it with any changes necessary (without having to re-enter the entire form data again).
[aside: in my GoMobile app I call this a âreinspectionâ ]
@Xiphware Thanks for linking to the new Collect feature. Itâs related but not what this feature suggestion is about. This only retains data from the most recently edited / added submission â not one that was collected and submitted days or months ago, even by a different user and device.
A lot of the changes relevant to KoBoâs infrastructure and UI depend on the ongoing discussion on how this could be implemented in Collect. Adam at ODK has written up a draft spec for the Collect roadmap. The accompanying forum discussion for this Collect feature is here.
Clicking on âsee submission historyâ, she can see the previous versions, including when and by whom they were submitted, and which fields were changed (highlighted through different color background).
We are doing a number of amendments while doing record validation, but have no way to see what was in the original submission from the enumerator vs what were edits made subsequently by the users doing the validation. Itâd be fab have the full audit trail of what edits were made and by whom (both changes to the submission itself and to its validation status).
Good question!
For my current use case, whilst a beautiful UI to see audit trail would be amazing I suspect it is fairly complicated to consider the scenarios - and I would be fine with just being able to access the history via a downloadable audit log with
submission id/uuid,
name field from form,
original value,
new value,
datetime change was made,
changeid (if poss - so can collect all the changes made at that time - though could use datetime if needs be provided saved synchronously)
user who made change
The audit log should also specifically show Validation status changes alongside all the content changes.
That way I could then join it back to the list of submissions and e.g. see all the changes made for a given districtâs forms, or whatever identifier from the data that I want to group changes together by. Sometimes Iâm looking at a specific submissionâs history, other times Iâm looking across multiple submissions (e.g. looking across a geographic area to find common issues that are requiring manual amendment at validation stage).
If additionally we could have a way of selecting a specific historic submission version to preview that would be great - though know that could cause complications when the forms themselves have been re-released in the interim.
Not sure if that is what you were after @tinok but those are my top-of-the-head thoughts
From the beginning, how do we prepare the forms (other than the default if any) or anything we should do with the server in order for the submitted data to be accessed and edited when collecting longitudinal or continuous data?