Hi guys, I am fairly new to the forum, so I apologize if my question is a lacking in the necessary details or doesn’t follow a standard format. Recently in an implementation we are running in Nepal, we were requested to add a picture in the person contact form. We have attempted and successfully managed to use images in app forms before and tried the same thing in the person_create contact form, which did not work as expected.
So the crux of the issue can be explained as a two-parter.
First off is the couchdb document when saving the contact. It does not have the _attachment field like the form data which you can see in the images below (App form document is on the left with _attachments and Contact form is on the right).
Both of the forms have used the type image in the the form and have no difference among them in terms of configurations and such. Both documents have the image names in the appropriate fields the _attachments field is the only difference.
Secondly, when I inspect the page and look into the image loaded in the report, it loads the image as a blob and does not directly reference the image file. Where does CHT store the images uploaded via forms? I was hoping I could directly reference the file location in the contact-summary.templated.js file and make it work that way but that does not seem to be an option.
TLDR; Trying to add image upload to person_create contact form is not working but the same thing works in app forms. How can images be uploaded to contacts so that they can be displayed in contact cards?
Thank you for your response @binod sir, if there are no alternatives, I guess we might need to rethink how we approach this issue. I will follow the forum for any updates on this feature.
Maybe I am missing something here, but the basic functionality of being able to include media in a form should work fine for contact forms. I agree with Binod that I don’t think we have done any work targeted specifically at fixing this, but have have had several significant Enketo uplifts that perhaps inadvertently address this…
I just did a quick test with the default person-create form and a CHT instance running 5.0:
Add image file to forms/contact/person-create-media/images/croc.png
Update the person-create.xlsx to reference the image:
type
name
label::en
image::en
string
name
Full name
croc.png
Convert/upload the form cht --url... convert-contact-forms upload-contact-forms -- person-create
After that, the image was showing in my contact form as expected:
Adding the image type in a contact form also asks you to upload a picture. However, that picture is not visible anywhere. It is not there in the attachments either.
Uploading files is only available for the main document. In this case, in your clinic create form, the upload would be attached to your clinic, and not the person. To upload a photo for the person, this needs to be done in the person-create or person-edit forms.
Hi @diana, this makes sense technically, but it highlights a real workflow challenge worth raising. In our context, CHWs often register households with 10 or more members at once. Following the suggested approach would mean the CHW completes the household registration, then has to go back and open a person-edit form individually for each member just to capture their photo. Essentially repeating the same step 10+ times for a single household visit.
In practice, this kind of repetitive workflow might result in CHWs skipping photo capture altogether, which defeats the purpose of the feature.
Is there any planned support for capturing attachments for sub-contacts directly within a parent form such as clinic-create? This would allow photo capture at the point of registration as part of a single uninterrupted workflow, and if this is not currently supported we would like to request it as a feature.
Please feel free to open a feature request to add the ability to add attachments for sub-documents.
I want to mention that this is technically complex and elaborate, and would need to be applied to reports attachments as well. The additional added complexity was the reason we did not pursue this in the initial work, and also because this was not described as a requirement, neither in the original description or in the course of developing the feature. This discussion was brought up several times, was discussed on the issue and the PR and was agreed to be dropped in the initial iteration.