-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
File download Step with partial name doesn't get provided in output #725
Labels
Comments
plocket
added
bug
Something isn't working
bite-sized
Well circumscribed small task
and removed
bite-sized
Well circumscribed small task
labels
Jul 11, 2023
plocket
changed the title
File with partial name doesn't get provided in output
File download Step with partial name doesn't get provided in output
Jul 17, 2023
This may become more urgent if/when SuffolkLITLab/docassemble-ALWeaver#894 gets implemented. Also, we may need to add an issue for handling multiple file name matches. |
plocket
added a commit
that referenced
this issue
Nov 21, 2024
The failure is actually during the comparison - the file was being saved using the partial name the author gave in the Step when it should have been using the file's downloaded name. Note that our current download method will, in ideal cases, let an author re-name the downloaded file. Since it might not be consistent, we might still avoid implementing this at this point. Also, in ideal cases, the Step does already continue without waiting for the whole file to download, which addresses #492. That happened a while ago. It's worth considering closing that issue at this point. We have to research under what circumstances a file would fail to download with a `fetch` while still being able to download with a click. Maybe with an encrypted interview. Co-authored-by: ethanstrominger <ethanstrominger2@gmail.com>
plocket
added a commit
that referenced
this issue
Nov 21, 2024
The failure is actually during the comparison - the file was being saved using the partial name the author gave in the Step when it should have been using the file's downloaded name. Note that our current download method will, in ideal cases, let an author re-name the downloaded file. Since it might not be consistent, we might still avoid implementing this at this point. Also, in ideal cases, the Step does already continue without waiting for the whole file to download, which addresses #492. That happened a while ago. It's worth considering closing that issue at this point. We have to research under what circumstances a file would fail to download with a `fetch` while still being able to download with a click. Maybe with an encrypted interview. Co-authored-by: ethanstrominger <ethanstrominger2@gmail.com>
3 tasks
A more detailed description of what turned out to be the actual problem is in the PR #959 |
plocket
added a commit
that referenced
this issue
Nov 22, 2024
The failure is actually during the comparison - the file was being saved using the partial name the author gave in the Step when it should have been using the file's downloaded name. Note that our current download method will, in ideal cases, let an author re-name the downloaded file. Since it might not be consistent, we might still avoid implementing this at this point. Also, in ideal cases, the Step does already continue without waiting for the whole file to download, which addresses #492. That happened a while ago. It's worth considering closing that issue at this point. We have to research under what circumstances a file would fail to download with a `fetch` while still being able to download with a click. Maybe with an encrypted interview. Co-authored-by: ethanstrominger <ethanstrominger2@gmail.com>
plocket
added a commit
that referenced
this issue
Nov 23, 2024
Fix #725, partial filename match for downloading fails
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
[Allow "download" Step to accept partial matches on filenames. This is important because some filenames have random characters in them from docassemble, so an author can't always know what the full file name will be.]
Right now, since there is a way the Step can work (using the full name with the extension), this isn't a high priority, but it would be very nice to have this worked out.
In in-Playground tests, the first test at Alaska ChidSupport defendant_paths.feature downloads a file. The test will pass with both a filename of
child_support
orchild_support_preview.pdf
, but a downloaded file will only be provided for the latter string. Not sure about GitHub tests yet.Examples:
The Step [is supposed to do] a partial match for the file name when looking for the document link. It's confusing that the tests would both pass, but one would correctly provide the file while the other doesn't. One theory I have is that somehow the download name of the file is affected and so it does get downloaded, but our code can't access it because it doesn't have an extension or something.
The text was updated successfully, but these errors were encountered: