Spec proposal: Editable submissions

Development
, , ,
1

As discussed in this thread, the ODK core team would like to make it possible to edit submissions after they have been finalized or sent in Collect. The intention here is that XForm instances that are edits of a submission will include a deprecatedId node in meta containing the ID of the original submission (along with a new unique instanceId). This is already how edits work in Central.

To avoid allowing this behaviour in projects or forms where it's not appropriate, we'd like to propose making additions to the XLSForm and XForm specs to allow opting-in on a form by form basis. The changes proposed are:

XForm

  • A new odk:editable attribute for the submission node:
    • If the value of odk:editable is "true", clients should allow sent submissions to be edited using deprecatedId as a way of linking edits together.
    • If the value of odk:editable is anything else, clients should not allow edits after submission (assuming they don't usually).

XLSForm

  • A new editable column in the settings sheet that's value will be used to define the new odk:editable attribute.
2

We've discussed this a little more, and wanted to make sure that it's clear that editable is meant to suggest behaviour to the client, so I propose we use client-editable instead.

3

So odk:editable is basicaly a hint to the XForm client that the (OpenRosa) server may accept - or, equivalently, wont immediately reject - a submission for this specific form with a deprecatedId?

4

This doesn't really interact with OpenRosa. The server should always accept saved forms (instances) with deprecatedId unless some other configuration prevents it, or it just doesn't support it at all. Here we want to inform the client that it should allow editing for sent/finalized saved forms for a specific blank form. There's more detail abut the motivations for this over in the discussion about the Collect feature.

5

I guess that's what I was getting at - if Central already supports 'editting' a submission (via OpenRosa) using deprecatedId, there would seem to be nothing to prevent a odk:editable unaware client from to continuing to basically 'edit' submissions in this manner if it were doing so already... Presumably even for a form that has now been designated odk:editable = false, right?(!)

Obviously Collect wont do this because it is going to abide by the (new) directive. But hopefully you understand my curiosity around what the actual submission API will enforce around this (if nothing that's fine, then it really is just a hint to Collect. But it would mean your form does remain potentially editable by other clients, if my understanding is correct?].

6

Yeah, that's spot on: whether a client actually honours this or not is up to them.

At the same time though, a server could be strict about editable = false and reject submissions with deprecatedId for that form. That's not something that's planned for Central as far as I'm aware, however.

7

Thanks for confirming my understanding. FWIW it might be worth highlighting this in the associated XLSForm docs for the new form setting: this is only a hint (to new versions of Collect) and doesn't actually make your form's submissions in Central non-editable by potentially other clients.

8

As discussed this will be updated so that it now reads:

XForm

  • A new odk:client-editable attribute for the submission node:
    • If the value of odk:client-editable is "true", clients should allow sent submissions to be edited using deprecatedId as a way of linking edits together.
    • If the value of odk:client-editable is anything else, clients should not allow edits after submission (assuming they don't usually).

XLSForm

  • A new client_editable column in the settings sheet whose value will be used to define the new odk:client-editable attribute.
9

didn't want to create a thread just for this - but a potential UX upgrade could be to improve error messaging on failed edit send.

First I received a photo showing failed send submissions mixed with successes on the screen, which is very unusual.

Then I received a photo of the upload results and I figured out pretty quickly what was happening - they never sent the earlier versions. Once they sent the originals they were able to send the edits.

From their POV, I think if the Uload result message suggested they send the earlier version first instead of only 'we can't find that submission', they are more likely to work out the issue on their own.

(this happened as it was set to manual send, so Collect couldn't auto send on connection and get them out in order)

image
image742×400 74.3 KB

10

As far as I can remember, the complexity here is that the error is occurring on the server. We could potentially do a better job of hinting about what's happened here or even just gating the scenario, but I think we'd need to see more evidence of edit finalized being combined with manual sending to prioritize it realistically.

One question though: was this an attempt to send all forms or were just these forms selected? Collect should sort the group of submissions by ascending finalized date before sending, so this should only happen in the latter scenario.

11

I was fairly sure what happened was the user hadn't sent the original and manually selected only the edit to send and not also the original. But now that i think about it, it's not possible to create an edit using a finalised but not sent form is it?

They were able to successfully send after i said (incorrectly?) that they needed to send the earlier versions first.

12

This isn't a scenario we'd be looking to prioritize fixing being honest. I'd advise training users to select all and send if using manual sending.

You can edit an unsent form as long as it's finalized.

13

Thanks @seadowg .

I'll focus on training, and reinforcing that they keep it in draft and only send when they consider it complete, and edits should only be sent if errors are noted or changes required.