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.
4 Likes
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.

2 Likes
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?].

1 Like
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.

1 Like
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.

1 Like