Qfield pictures going into Files folder
Describe the issue
Qfield pictures now going into a folder called "Files". It's also losing the .jpg or .png extension.
Reproduction steps
Steps to reproduce the behavior:
- Take a picture on Qfield
- Connect mobile device to a laptop/PC and use File explorer to go to Tablet folder location. For us, it's This PC\TB85Plus\Internal shared storage\Android\data\ch.opengis.qfield\files\Imported Projects\
- Open project, then go to Files folder.
Expected behavior
The pictures used to go into the folder "DCIM" and they had the .jpg extension
Observed behavior
Not sure what to put as already mentioned
Screenshots and GIFs
[Please also attach additional files if a specific project/dataset is useful to investigate the problem.]
Desktop (please complete the following information)
- OS: Windows 10/11
Mobile (please complete the following information)
- Device: Unitech TB85
- OS: Android 8
- QField version: 3.0.7
Additional information
- Problem started happening recently, didn't happen in an older version of QField: Yes
- Problem can be reliably reproduced, doesn't happen randomly: Yes
- Problem happens with all files and projects, not only some files or projects: Yes
Can I make a request that these pictures go back into the DCIM folder and retain the .jpg extension please?
@connorjfns , that sounds like a project setting issue to me, can you share the expression you've set for the photo attachment's path in the vector layer properties dialog, i.e. this:
@nirvn So, by default I use the expression below (the part after DCIM varies based on layer) 'DCIM/chambers-and-notes_' || format_date(now(),'yyyyMMddhhmmsszzz') || '_{filename}' || '.jpg'
But sometimes the QGIS changes the formula above to the default one (PSB). This happenes when the project is opened with the older QGIS version and sometimes it happens like randomly for reason I can`t detect. 'files/objects_' || format_date(now(),'yyyyMMddhhmmsszzz') || '_{filename}'
My observation though is that this seems to change with the qfield version without any changes on our end to the project settings. For example, if we did a project in Qfield version 2.6.2, the pictures would go into DCIM. If we worked on the same project from any version from 2.8.0 onwards, the pictures would go into Files.
Which QGIS versions are you using? Can you share an affected file with a description of what's affected?
Hi, we are using QGIS version 3.22.11 On our Tablets, we are using latest version of Qfield 3.0.7
I have uploaded 2 files. The folder named "Correct-work" is when we worked on a project using qfield version 2.6.2. the other folder named "Faulty-work" is the same project, but on qfield version 3.0.7
In the correct work folder, the pictures are stored in the folder DCIM with the .jpg extension. In the faulty folder, the pictures are stored in the Files folder with no extension.
Seen also here on several different devices.
The QField project highly values your report and would love to see it addressed. However, this issue has been left in feedback mode for the last 14 days and is being automatically marked as "stale". If you would like to continue with this issue, please provide any missing information or answer any open questions. If you could resolve the issue yourself meanwhile, please leave a note for future readers with the same problem and close the issue. In case you should have any uncertainty, please leave a comment and we will be happy to help you proceed with this issue. If there is no further activity on this issue, it will be closed in a week.
@connorjfns , looking at the faulty-work.zip project, I can see one configuration issue. You should set your attachment viewer type to image, that provides the hint for QField to through images in DCIM by default:
In your case, you'll also need to tweaked the preexisting attachment expressions here:
@connorjfns , is this still an issue?
The QField project highly values your report and would love to see it addressed. However, this issue has been left in feedback mode for the last 14 days and is being automatically marked as "stale". If you would like to continue with this issue, please provide any missing information or answer any open questions. If you could resolve the issue yourself meanwhile, please leave a note for future readers with the same problem and close the issue. In case you should have any uncertainty, please leave a comment and we will be happy to help you proceed with this issue. If there is no further activity on this issue, it will be closed in a week.