Client_editable (not quite) True (for Entity updates)

1. What is the issue? Please be detailed.

Summary: Editing a sent form on a device to change Entity selected (form updates an Entity) causes a potential Entity version conflict on Central, and does not update Entity status for the edited submission.

NOTE: No enumerators were harmed in the making of this post.

Context

A field survey required enumerators to visit predetermined plots and collect data at that location. These points were created as entities and, after completing a submission, an update to marker-color gives a visual guide to progress. Each enumerator has a set of points to complete (coloured per enumerator to avoid duplication when working offline) and after sending submissions (daily) the Entity List updates the marker-color for all entities that have been visited. This means the Supervisor can see progress without logging-in to Central (useful if the Supervisor is also collecting data and/or doesn’t have access to Central!) and enumerators can see overall daily progress.

SCREENSHOT: Subset of the data (select_one_from_file, map appearance) - markers are entities and the offline layer shows dots in different colours with plot numbers)

The Problem

An enumerator sent a submission which had the wrong Entity selected: #19 instead of #26 (beyond scope to ask why - a sensible answer is not available!). Therefore #19 was updated when #26 was visited, and #19 had already been updated when #19 was actually visited (by another enumerator!)…

On checking the data at the end of the survey one plot had not been updated (#26) but it was not possible for the Supervisor to see that #19 had been incorrectly updated. There is no mobile or wifi signal at the site, so updates are only possible at the end of each day. In this case, the enumerator was able to demonstrate that the submission had been sent (on-the-fly map showed the submission location thanks to a geopoint question that confirms exact location!)

The enumerator then edited the SENT form, selected the correct Entity and resubmitted the form.

EXPECTED BEHAVIOUR: that the Entity list on all devices would be updated to show that #26 had been visited (i.e. fieldwork complete). Probably not possible to resolve the entity conflict for #19 automagically!

ACTUAL BEHAVIOUR: submission value of selected entity was updated but no change to the Entity List on any devices.

It is (probably) reasonable for an enumerator to assume that their edits will update the Entity as well as the submission (the enumerator does not have insight into form function and data management!).


When downloading the submissions from Central (using QuODK) the EDITED version was available showing #26 as complete; the entity list showed #26 not updated.

Why is this ‘important’ (to me)?

In this case, the site is 6km walk across featureless peat bog from the overnight base. The enumerator was ‘threatened’ with having to collect that data as a separate trip! It is also 1 day travel to get to the base, so worst-case scenario could have needed 3 days to collect one point if this hadn’t been resolved before leaving site… e.g. if the Supervisor had not been able to see the enumerator’s device (usually the case!) - maybe sharing a screenshot might have worked, but I worked out the problem based on trawling submissions on the enumerator’s device, although the enumerator had no easy way of fault-tracing…

2. What steps can we take to reproduce this issue?

Create a form with client_editable set as true AND use an entity list, which is updated on submission of a form (e.g. change status / colour etc).

Select an entity and submit the form.

Edit the submitted form on the device and change the selected entity then resubmit

View the Entity list status and the submission history.

NOTE: the conflict for the entity is for original entity selected (because the real submission for that data point updates the original entity as well) but entity selected during edit is not shown as updated.

3. What have you tried to fix the issue?

Make the enumerator collect the data again :slight_smile: (not really)

Create a ‘dummy’ submission with the correct Entity selected - this updates the map, both offline and after update.

4. Upload any forms or screenshots you can share publicly below.

ODK Collect - select Entity from map (on Supervisor’s device):

Note: #26 marker is X and still cyan (not done); all other markers are - and green (done). Offline map layer shows plot numbers

Form submission:

Note that the edited submission (20:46) changes QuadratId (which is the Entity reference #19#26) but does not update the entity itself…

Entity #19:

Note: v3 is the correct submission; v4 is erroneously selected ‘duplicate’.

Entity #26:

With a little offline discussion with @ahblake it looks like I missed something important from the docs… https://docs.getodk.org/collect-forms/#editing-finalized-or-sent-forms

“Edits to submissions that create or update Entities are allowed but they will only modify the submission, not the corresponding Entity.”

Which means a bit more thought on how to avoid this happening in future. One obvious suggestion (thanks @ahblake!) is to use geofencing to prevent selection of an obviously wrong plot… Any other answers / suggestions welcome.

So maybe this is more of a ‘Pitfalls in data collection with Entities’ rather than a support question… and a +1 for ‘could editable submissions update the entity as well’ :slight_smile:

1 Like