Update an already-submitted record on a mobile client

#1

What is the general goal of the feature?

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

#2

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:

  1. Enumerator collects data, submits it to the server, e.g. a household registration at the beginning of a relief program
  2. Several weeks later, the survey administrator wants to conduct an update of the form, enabling ‘allow record updates’ in the backend.
  3. 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.
  4. 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.
  5. She is able to scroll through the questionnaire, checking if all registration items are still accurate
  6. If anything has changed (or was incorrect), she makes changes to the data and saves the record.
  7. The submission is queued as usual to be submitted upon reconnecting the device to the Internet.
  8. When the program admin checks the dataset, she sees the updated record in the database.
  9. 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?

1 Like
#3

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.

#4

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

#5

You may be interested in following the development of a new feature in ODK Collect, described here: https://forum.opendatakit.org/t/remembering-previously-entered-value-in-odk-collect/9116/34

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” :slightly_smiling_face:]