Omit file paths when using directory sync in a version controlled directory
Hello, I’ve had a chance to give the directory sync feature a try and found that when using multi-part form data, if I add a file in and then check the synced directory, it also stores the file path in there.
I think this would be fine in non-version controlled directories, however when it’s in a version controlled directory, it would be great if this file path was omitted as it may not exist in the same location on other machines.
(More of a nice to have) perhaps in the version controlled scenario it could also keep the field type so it would be obvious that a file was required for that field, but still have it stored on disk without a path.
Cheers!
Mac2025.1.2
I think that makes sense. I can imagine changing it to never store the file path directly in the request data but instead store a reference to a user-selected file path which would be excluded from sync.
Form data entries already have an
idfield to uniquely identify them. Yaak could add a new “Attachments” model (excluded from export and sync) and store the user’s file selection under an Attachment with thatid.I think there is a valid use case for syncing the file path if the user located the file within the workspace sync directory, but I’m not sure it would be common enough to justify supporting.
That sounds even better!
My primary goal here was to prevent the constant need to either commit or reset the change due to the file path being dependent on the user's machine. But that sounds like it would both fix that issue and still allow the attachment id to point to the user's chosen file (whether it be the same or different file) on any given machine.
Would love to see it! 🙂
As for the latter point, I guess the only advantage there would be that the attachment id would point to a relative file path by default, which could be useful to someone or a team. It's not something I'm looking for though, so no deal breaker for me personally.
Edit: On second thought, it could be useful for easier testing scenarios in a team based workflow, i.e. write your request, point it to a committed file, commit & push etc… QA picks up the testing and can easily verify yep, it uploaded the file. Maybe niche, but where I work, we do sometimes have QA test backend functionality if it’s a large piece of work where there is no UI yet, or if it’s simple just an API endpoint for internal/external consumption. So there could be some value there!