What is the general goal of the feature?
We have several web-forms that use Enketo Grid Theme, with complex repeat logic. When admins want to view submissions afterwards, if we view them using the ‘single-submission modal’ view (from the data table, clicking on the little eyeball), then it is difficult for non-technical users to match up which data points relate to which parts of the Grid Theme form.
We would like a way for users to be able to view the forms exactly as they were submitted by the enumerator (i.e. using Enketo), without having to give edit access to those that don’t need to edit.
What are the most likely user stories for how and when this would be used by someone on your team?
As a validator, I can view the submission in its original layout, without having the risk of accidental editing.
I can print/pdf the submission just as it would have printed if the enumerator had hit print before they submitted the Enketo form.
(future state - for bonus points) I can run a script to automatically pdf submissions - I have a way of doing this in bulk via scripting but would need a URL that is stable (i.e. doesn’t time out after 30s like the edit URL as mentioned in a prior thread.
Can you sketch out graphically how you think this should look/work in practice?
An extra icon on the Data View screen that takes the user to the Enketo view of the form but where data can’t be submitted (ideally where the URL is a format that can be constructed from fields in the data download…)
How useful would this feature be to other users or organizations?
useful, based on the multiple threads about viewing/printing completed submissions.
What can you contribute to making this feature a reality?
Test support
Interested in others’ views too. Thanks for considering!
So maybe your suggestion would work if there would be a printer like print button alongside the eye like preview button and the pen like edit button. This would save users time to go inside the submission by clicking the pen like edit button. In addition, if a certain user is provided with view submissions, the user could also print the submission if needed.
Thanks @Kal_Lam ! Yes the "printer like print button alongside the eye like preview button and the pen like edit button" option would be magnificent to cater for my use case #2 above. And if it was a URL that we could easily get programmatically then that would also cover use case #3.
Use case #1 doesn’t need a pdf though - our validators just need to be able to open in Enketo without risk of editing the submission (especially now that giving someone ‘edit’ rights also means they can delete the submission too).
Print selected in selected menu (similar to delete there)…
For the role rights: Do we want everyone who has view right (even on raw level only) to be allowed to print? The (standard) print from View mode includes ALL variables. e.g… hidden, calculates and internals like username.
Hint: The print output from View mode (eye) and from Edit mode (pencil) are rather different in style and content, and from Edit the pdf is much longer. So, for a new multiple print option, we would need to decide which one is preferable (or add a style choice option).
Re the pdfing, I have just found out that Enketo already has an API that allows one to download a PDF of a submitted record (without showing skipped fields) - and apparently it is already implemented and works well. This would be PERFECT for me (we have lots of skip logic and repeat groups etc. so it would be fab if they were hidden).
If the pdf piece (use case #2+3 above) is already available in Enketo does that mean it’s already available in KoBo too somehow behind the scenes?
So, the Enketo API documentation to create a pdf is at API Documentation
My request is now for KoBo users to please be given an endpoint to access the Enketo post-instance-view-pdf functionality via the KoBo API.
(if a button can also be added to the UI then great! but direct API access would get us a long way).
Hi @nat, I’ve implemented your requested changes, minus the PDF option for now as it requires some more configuration on our side. You can follow the change here for when it might be merged into production.
Hi @Josh hope all’s well. Just wondering, do we know when the power to create a pdf might be available on KoBo? And/or ability for a validator to view a form in Enketo without having the power to edit?
Know you’d made a change for the latter piece a few months ago but not sure how long it takes to integrate.
Thanks loads and best regards!
Hi @nat, we had a look at integrating the PDF creation but due to security issues it would introduce on the server, we decided not to proceed with it at the moment. Regarding a validator, that is certainly a valid feature request but it’s currently not in the pipeline.
Regarding the view-only change, that is still coming but was unfortunately put on the back-burner — it will hopefully be integrated soon
Dear Kobotoolbox community,
in reference to @nat additional request, would like to point out that an endpoint to access the Enketo post-instance-view-pdf functionality via the KoBo API would be really wonderful.
Requested in the case of bulk pdf export need (pdf format more reliable to audit than excels).
The new endpoint '/enketo/view" is great but for information, we have tried to automate the pdf export via request, Selenium or pdfkit in python using it without success.
Happy to share our tests.
A direct access to pdfs via the api would be so handy!
I would love a way to batch download PDFs from the records! This functionality does exist within the enketo API, but isn’t implemented in Kobo as far as I know.
At the moment we have to click on each record in the data table, then click ‘view form’ and print to pdf one by one, which is suuuper slow when you’re talking about thousands of records.
My desired functionality would be to have a search function on the dataset inside the web platform, ideally it lets you use any column as a filter so we could highlight for example all records from one surveyor, from a subset of villages or provinces, or all records from a specific date range. If thats too complex to implement it could just be filters based on the standard metadata.
Then you would click ‘select all results’ and click download records, outputting a zip of all the pdfs for the selected records. Even better would be if you could specify the folder structure within the zip based on the values in specified columns, so we could download records automatically sorted into for example village_name ->year_month. → pdfs
It wouldnt matter if the speed was throttled or you limit to 1 record per 30s or whatever you need to do to stop bandwidth issues…, it would save us huge amounts of time in post processing to be able to do this in one click even if the download takes all day.
