I am using the following expression as my filename:
‘DCIM/SFFF_Photos/’ || replace(“Retrieved_Farmer”, ’ ', ‘') || '’ || replace(“Retrieved_Paddock”, ’ ', ‘') || '’ || to_string(“Retrieved_Scout_Date”) || ‘’ || to_string(“Retrieved_Plantain”) || '%’ || ‘ID_’ || format_date(now(), ‘zzz’) || ‘.{extension}’
I have multiple users currently submiting forms with attachments, and some of them are coming correct with no issue and some of the attachments are coming with a JPG name:
Good example inside DCIM/SFFF_Photos/Rimoo_Farm_42_2026-03-10_3%_ID_309
Bad example inside DCIM/JPEG_20260310020244199
When checking my table the ones with the wrong naming didn’t populate the attribute table correctly in the first place.
Any ideas?
Thank you in advance.
Hi and welcome!
Have you verified that they have an updated/correct version of the project? the /SFFF_Photos/ part of your expression is hardcoded, I don’t see a reason for a possible bug in the expression to remove that, so my best guess is that some of your users are using an old version of the expression.
Besides that, can you include your expression inside of a code block so we can better check if everything is written properly? You can use the “Preformatted text (Ctrl E)” button on the toolbar above the response text field:
And another question, what are you trying to achieve when using the replace(“some_text”, '', '') function?
@cuprico Could this happen by attaching photos taken outside of QField? E.g., if I download a picture from Google called “ninja.png” and attach it to a feature, would the image be renamed according to the expression, or would it be placed inside the default attachment directory as “ninja.png”?
The “bad example” naming scheme looks like something the camera app would do.
hmm, good point… will see if I can try this myself, but if that’s the case, maybe it can be a bug on QField then? Something like it might ignoring the expression if you attach an image file instead of taking a picture. Although, maybe OP is using the expression as a default value? In that case, it seems appropriate to “overwrite” the default with the name of the file.
I’m not shure how QField implements the taking of the picture while simultaneously writing a path on the layer attribute, since those two processes have no relation per se. It might even be different for the “internal” camera and the phone’s camera (reinforcing your point @fggs-pascal ). I’m imagining that the qfield internal camera could take advantage of the default value parameter and use that as a save path, leaving the attribute form to take care of the actual writing on the layer; while the phone camera would just save the image and return a path on exit, forcing QField to paste that path and ignore the default value. But I’m just rambling…
I believe I found the problem. I will blame the users!
I am using attribute(get_feature(‘Scouts’,‘ScoutingUUID’,“UUID”),‘Plantain %’) to populate the Retrieved_Plantain field for example, the problem is the user is inputing those fields to the form, and they decided to take photos first and decide to enter the information later.
I have put a conditional on the photo tab to only be visible once the information has been entered. Second day of the project ran with zero errors. Not the perfect work around as people need to walk the field and take photos before they make a decision, but the managers want the % on the name of the photo files.
The other thing I did was replace the layer naming from ‘Scouts_72930368_7713_4f5e_a140_457d37ebdebb’ to ‘Scouts’ and had no issues with some of the fields not being populated correctly.
Thanks for the help team.
2 Likes
Interesting, thanks for sharing your solution.
What if maybe you can have a “scouting” layer, where people could just be taking pictures and taking notes, with an optional boolean attribute (defaulted to false) to flag features as “worthy to enter information for managers”. The people on the field can decide to enable for further processing or not this feature, now or at a later time (by editing the already created feature).
Then maybe you can have a second pass, as automated as possible, that deals with preparing the data for the managers, scanning for this flag. I think this could be implemented in a second layer with expressions that fill its attribute fields using the “scouting layer” as reference. Maybe it can even be omitted from the QField project and only present on the desktop project.
