What is the problem? Please be detailed.
In the XLSForm.org page there is a question type:
"file Generic file input (txt, pdf, xls, xlsx, doc, docx, rtf, zip)"
So I tried this by adding a question with type file, hoping that it might allow me to select a file on my phone to include in the submission (a media attachment). The form converted without issue on the online converter.
On opening the form I am presented with a text box, not a file select option.
This question type would be a handy way of including other datasets that should be associated with an ODK record (in my case a gpx track - which might not work give the file type!).
What ODK tool and version are you using? And on what device and operating system version?
Excel spreadsheet, online converter,
Collect 1.13, Galaxy Note 4, Android 6
What steps can we take to reproduce the problem?
I assume you could try building a form with question type as 'file'
What you have you tried to fix the problem?
Not sure what I could do from the information available on Open Data Kit website - this question type is not exposed in any other documentation.
Anything else we should know or have? If you have a test form or screenshots or logs, attach here.
Has this question type be depreciated (maybe for security reasons)?
Hi @seewhy! It's in the spec, but I believe it's only been implemented in Enketo.
To implement this, we'd need to add a new widget to Collect and support in Aggregate. It sounds like you'd like this feature, so I'm moving this thread to the Features category so we can discuss it.
This feature seems like a pretty easy win, so I'd like to understand more about what it'd take to implement. I'm particularly concerned about how we deal with mimetypes and very large files.
@Grzesiek2010 Can you think of any reasons why this would be tricky to implement on the Collect? @ggalmazor What about on Aggregate?
@ln Anything else we should be aware of from the spec side of things?
I was thinking about such a widget some time ago but I'm not a real user and I wasn't sure if it's useful so I didn't talk about it. It shouldn't be complex on the Collect's side (at least I can't imagine any risk now) so I think we can go ahead.
Hi @yanokwa and @Grzesiek2010
Thanks for your replies - glad it wasn't just me being unable to read the manual!
I'm sure that this is a daft suggestion, but this almost works already with 'choose image' in the camera widget (except of course it fails as an unsupported file type), so perhaps there is code almost ready to go.
If you are considering this as a new feature it would be great to be able to specify the supported file type(s), which will help the collector - this could be an attribute or constraint? If you could filter out files based on type that would be a great safety net
I can't really see why you'd need to limit file size (I know some people would be worried about bandwidth and storage in aggregate), but could that be another constraint in the settings. There would be nothing more frustrating in the field than having a file very slightly too big to include (and not have the tools available to edit it!). You could put a message on collector if the file is over a given size asking for confirmation?
Appreciate your positive approach to problems! They become opportunities
Thanks.
Hi @seewhy! Just wanted you to know that @Grzesiek2010 is currently exploring how best to add this feature and I'm hoping we'll have something to share soon.
I hear you that being able to filter out type would be useful and that size filtering might not be. Do others have any thoughts on type or size filtering?
Thanks for the update. Is 'exciting' the wrong word to use? Does it expose a certain personality disorder / trait? Anyway, that's great news that it's getting the @Grzesiek2010 treatment!
My thinking about size / type is that it should be possible to anticipate the file type for a given question and therefore set some parameters for acceptable attachments, but it could be detrimental to limit the size of file... But I don't know what the implications are for my desires.
We do already have a special header that a server such as ODK Aggregate publishes (X-OpenRosa-Accept-Content-Length) that specifies the max size in bytes of a submission batch (where a batch is a part of a single record split into multiple pieces). Since a file cannot be split across multiple batches, this header can therefore be considered the max upload file size and the client can prevent users from uploading larger files (ignoring the size of the XML file which is sent with every batch).
In Aggregate the default is 10 Mb, I believe, and probably is the same across all forms, but it doesn't have to be. You could consider a feature whereby this can be set per form (in the Aggregate UI). It kind of makes sense to me to not set this in the form format itself but as a form deployment variable, unless you really need per-question control.
Note that all files will be allowed so I would only recommend using this is you trust your data collectors. Also consider making sure files are verified by an antivirus program before opening them on your computer.
Note that files can't currently be attached from Google Drive but this will be fixed shortly.
In order to prevent malicious file, we should consider limit files types maybe by defining some kind of parameter like type=pdf,xls,doc etc. By default all except (exe, ini).
