I have a need to visually display individual form submissions to some users. However, my form uses a number of calculates, pulling data from attachments, which get periodically updated, changing key values and causing whole parts of the form to change or not display.
I want to display the original submission values to users without re-calculating anything - e.g. displaying an uneditable pdf of the form submission. Is there a way to do this in Central/Enketo without modification? Does anyone have a workflow that they use to do this currently?
It looks like the /instance/view/pdf endpoint in the Enketo api might do this, but I'm not sure if that re-evaluates form data on generating the pdf or not.
Any thoughts or suggestions would be much appreciated!
Agreed this is important, and it's something we're thinking about a lot in the context of Entities which are currently attached to forms in as CSV attachments.
You can mitigate some of this in form design. For example, if you're looking up an entity based on some value like an id, you can have the calculations that get the values of other columns for that entity only be triggered if the id is changed (using the trigger column). This may not be practical for the current state that you're in but I did want to mention it.
If you have ideas on how to communicate about which version of a form and its attachments are being used to display or edit a form, please share. We'll follow the experiment you described here with interest.
I ended up changing gears on that Enketo experiment, mostly due to time constraints. Instead, I set up a python script that scrapes a submission's XML and the xlsx form definition to display a rendering of the form as it was filled as of its most recent edit.
Combining this with ODK Central's existing API endpoints to get the submission XML of any given submission (for any version of that submission) and any given xlsx form def (for any version of that form), you can create an accurate read out of the form as it was submitted (either originally or with any edit). This way, you don't have to manage attachment versions at all, because the original data is stored in the xml anyway.
Weaknesses to this approach:
The script does not replace choice names with choice labels for select questions generated from attachments, which makes those question answers harder to read with plain english. Theoretically fixable by downloading and parsing the attachments as well.
You have to manage downloading these items, running the script, and then spitting out the html file back to the user yourself. This works for us because we have our own frontend that sits on top of our data anyway, but may not for other users.
Here's a link to a git repository with the script (heads up to anyone stumbling across this at a later date, I may not be publicly maintaining this). Maybe it will be helpful to someone else at some point, feel free to use!