Update an already-submitted record on a mobile client

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

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?

2 Likes

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

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

1 Like

@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).

I would be very keen to see the ‘submission history’ (i.e. edit history) made available when users edit submissions via the KoBo website (modal / edit)

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).

2 Likes

Looping in our lead designer @ig_rebollo since this is a request that recently came up in a separate discussion as well.

As far as I can tell there is a need to have a list of edits per record but also per project (who last edited the form, added a new collaborator).

On the per-record edits, the question is how to display the changes, e.g, with a dataset that has hundreds of columns. Any suggestions @nat?

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

2 Likes

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?