bulk-submission-form doesn't accept non-image attachments

[nicopace]

When using the bulk submission form, it's possible to upload ZIP files containing XML submissions and their corresponding attachments. However, the current implementation only accepts JPEG files as attachments, excluding all others.

The relevant code is:

kpi/kobo/apps/openrosa/apps/logger/import_tools.py

Lines 86 to 89 in d646402

	with django_file(xform_fs.path, field_name="xml_file",
	content_type="text/xml") as xml_file:
	images = [django_file(jpg, field_name="image",
	content_type="image/jpeg") for jpg in xform_fs.photos]

This behavior is incorrect. The expected logic should be:

• Exclude the XML file itself,
• Include any attachment referenced in the XML submission, regardless of its file type or extension.

This limitation prevents the use of valid non-JPEG attachments (e.g., PDFs, audio files), which are supported in other parts of the platform.

Thanks!

[tiritea]

FYI I've confirmed this behavior also, specifically audio file attachments cannot but uploaded via the bulk-upload interface, but images can. Presumably, looking at the code above, its likely nothing but images can be uploaded (!). This is especially problematic for audio files, because it makes it impossible to get background-audio files re-submitted, because these are not exposed via the Enketo edit interface (whereas it is still possible to patch in other attachments after-the-fact via editing the submission in Kobo).

There is also no indication in the bulk-upload interface that certain files have not in fact been uploaded. That could cause a user to inadvertently delete and loose their original submission data, thinking it had been safely uploaded into Kobo when it fact some attachments were not.

[tiritea]

FYI some further background here: https://community.kobotoolbox.org/t/xml-submission-via-bulk-upload-works-but-audio-file-is-not-attached-500-error/70891

[nicopace]

FYI I've confirmed this behavior also, specifically audio file attachments cannot but uploaded via the bulk-upload interface, but images can. Presumably, looking at the code above, its likely nothing but images can be uploaded (!). This is especially problematic for audio files, because it makes it impossible to get background-audio files re-submitted, because these are not exposed via the Enketo edit interface (whereas it is still possible to patch in other attachments after-the-fact via editing the submission in Kobo).

There is also no indication in the bulk-upload interface that certain files have not in fact been uploaded. That could cause a user to inadvertently delete and loose their original submission data, thinking it had been safely uploaded into Kobo when it fact some attachments were not.

is there a timeframe for this to be fixed?
Can I help in any way?
REgards.

[noliveleger]

Hello @nicopace , we accept contributions. But you need to comply to our Python coding rules though ;-)
Follow the template checkboxes and then you can submit your PR. Please make sur to add unit tests.

[nicopace]

Thanks for the encouragement @noliveleger .

I did my best to do a comprenhensive reporting so people more involved in coding could carry on with the task.
I regretably lack the time to dive into the implementation details of KoboToolbox, as most of my time I spend it in user facing tech support for Indigenous communities, so I can't dive into this issue, as simple as it may seem.

I can commit to do user testing to verify its behaviour once implemented for sure!

[nicopace]

Just for completion, it seemt that @p2edwards fixed it, it got accepted.
How can I tell whether it is already deployed in production?

Thanks!

[noliveleger]

Hello @nicopace,

It's part of the next release which is still in QA. It should be deployed soon (~2-4 weeks).