Add ability to preview form definitions and edit submissions for forms that are closed or closing #469
Comments
|
At a high-level, for closed and closing forms, we want submission edits to work but submission creation to continue failing as it does today for closed. An idea to perhaps look into: I believe Enketo will be requesting the formList from a URL that has |
lognaturel
changed the title
|
Here's an attempt to capture the text above:
(edit: keeping the table updated) |
|
All values in the currently permitted? column confirmed locally ✔️ |
|
Is there any way to check if a form is a draft inside the |
Given https://github.com/getodk/central-backend/pull/530/files#diff-b48115a435dee55dae6048783669f3de6e30e561e4ed20195d0be48fad879c50R113 I think you've been able to satisfying the underlying need, right? Let us know if not! |
|
@lognaturel which cases are missing from the table in #469 (comment)? Would they be:
|
|
I'm not visualizing how the cases you outlined would match with the table! I agree that the 4 areas of functionality you outlined are likely candidates for change, both for OpenRosa and REST. At least that would be the case if we try to solve this with minimal Enketo changes.
That said, I think we should consider reverting #530 because of the inconsistency between OpenRosa and REST and because it makes something possible by API that's not actually possible through Enketo. Enketo won't be able to load a closed form for edit currently. If I recall correctly, the main challenge in this work is that currently Enketo uses the OpenRosa I believe the best option we've discussed is for Enketo to provide that information in something like a custom header or perhaps a The other thing we've mentioned is that we could explore opportunities for tighter integration with Enketo. For example, could Central manage the transformed form and pass that to Enketo? That way it could be entirely responsible for deciding whether a certain use of the form is allowed. This may not be something we get to for a while. Since we created this issue, another thing that came to mind is that we should probably also introduce a read-only form state that prevents any edits from happening when we do this work. |
This reverts commit 8377a0f. This commit may be re-introduced alongside similar changes to the OpenRosa API. See: getodk#469
|
Once ODK Web Forms are fully in place, this should no longer be an issue. That's because Frontend will request the form XML and pass it to Web Forms and won't have any difficulty doing so for closed or closing forms. It seems to me that this issue stems from how Central communicates with Enketo and will naturally be resolved once we swap out Enketo for Web Forms. I don't think we're planning to prioritize this issue before we swap out Enketo, so I think we could go ahead and close out this issue as a "won't fix". @lognaturel, how does that sound to you? |
There are three form states: open, closing, closed.
How form states operate with ODK Collect and OpenRosa
The three form states map very well to ODK Collect usage:
From an OpenRosa API standpoint:
formList, submissions accepted bysubmissionformList, submissions accepted bysubmissionformList, submissions NOT accepted bysubmissionHow form states currently operate with Enketo and what should change
The form states don't currently work well with Enketo because we use Enketo for different purposes:
Currently form-filling links (1 above) work as desired for the three states1 because that usage is very similar to Collect's. It's important that this behavior stays the same. It's NOT enough to block the buttons for submissions from Central Frontend because people distribute Enketo links directly. Specifically, form-filling links should work as follows:
Currently, previews (2 above) and edits (3 above) are also affected by form state changes but they should not be:
formListrequest to Central. Currently Central always returns the sameformListcontents which is filtered by form state.submissionrequest to Central to submit an edit. Currently, whenever Central receives asubmissionrequest, it uses the form ID in the submission XML to check the form state, then uses the state to determine whether the submission should be accepted. Right now new submissions and edits behave the same in this way.A note about form drafts
Enketo can be used to preview a form draft and fill a submission to it. However, form drafts aren't related to form state: you can use Enketo links for a form draft regardless of the form's state. Under the hood, form drafts use a different set of OpenRosa endpoints from published forms, prefixed with
/test. Those endpoints contain a token, so if you have a link to preview or fill a form draft, no auth is needed. It's not possible to edit a draft submission in Enketo.This is only intended as background information. Because form drafts aren't related to form state, nothing about those endpoints should have to change for this issue.
enketoIdand how Enketo links are structuredThe three uses of Enketo above — collecting new data, previews, and edits — result in Enketo links with a similar structure:
/-/<enketoId>). Users also know they can add/x/to the URL to get an offline-capable view (/-/x/<enketoId>)./-/preview/<enketoId>)./-/edit/<enketoId>).Each published form has an
enketoIdproperty used to construct these links. You can see how these links are constructed in Frontend in theEnketoFillandEnketoPreviewcomponents.Each published form also has an additional
enketoOnceIdproperty that is used with single-submission Public Links. It's important to know that each form can be associated with multiple Enketo IDs.Form drafts have their own separate
enketoId. Publishing a form draft does not change theenketoIdof a form that is already published.An Enketo ID is generated when Central sends a request to Enketo specifying a
server_url.Next steps
Allowing edits in the closing state looks like a good first step because it only requires changes related to
formList. This would likely make for a targeted first PR to discuss. It should keep in mind the following two requirements:formList.submissionendpoint. Currently submissions are rejected based on closed state before they're identified as new vs. edit.@matthew-white's original writeup
Show original writeup
Right now it is only possible to edit a submission if the form's state is open. We explicitly disallow editing for a closed or closing form: 6c5708d. I think that's because when we allowed it, the QA team encountered Enketo errors. Possibly two different errors seen here:One idea we've discussed is passing Enketo different endpoints from the regular OpenRosa endpoints. I checked, and from what I can tell, we currently have Enketo use the regular endpoints. We could pass Enketo alternative OpenRosa endpoints that would list/allow closed and closing forms.
Question: we could start passing Enketo different endpoints going forward, but would that do anything for existing forms? Is there a way to change this behavior for existing forms without changing forms' Enketo links?
Footnotes
Almost. There's a problem with the offlineable view. In Collect, submissions are separate from their form defs so the form definition can disappear but form submissions can still be sent. In Enketo, you need to be able to load the offlineable view in order to see the submission queue and submit. That means if you have offline Enketo submissions for a form in the closing state, you need to be able to load the page (or make sure not to refresh the cached version) to submit them. Let's consider that separately. ↩
The text was updated successfully, but these errors were encountered: