Not sure whether this is a bug or change that I've missed (can't see anything in the docs relating to it) however when using the download function from the PDF viewer, whether that's from the app component or from the storage view, the filename now looks to be the file id (or some other hash) rather than the acutal filename, which isn't helpful!
This looks to be a recent change as it was downloading the file with the filename just last week.
I also have this issue. It was working about a month ago. I have a process which runs once a month and the filenames are now nonsensical - not sure why.
Hi @stu - thanks for flagging this! Thanks, as well, to @Paull for the confirmation. Welcome to the community!
I think I know the likely cause for this change in behavior and will talk to the team in order to confirm and see what we might be able to do about it. Just for the sake of clarity, this only seems to be an issue when downloading files from Retool Storage. Let me know if you're seeing otherwise!
I'll let you know here as soon as I have an update!
Hi @Darren
Thanks for your reply.
I'm just checking in on this. Did you manage to replicate the issue? Is there a fix in the pipeline? Do you have an idea of the timescale for a fix?
Thanks so much!
Paul
Hey @Paull - it's a relatively simple fix, but not one that has been prioritized just yet. As such, I don't really have a good estimate of how long it will be until we can roll out an update.
Thanks for picking this up and confirming that the likely cause has been identified. Out of interest, what's Retools policy regarding breaking changes, such as this? I appreciate it'll be prioritised in-time but as there was no forewarning, presumably it was unexpected?
Hey @stu - breaking changes that cause true production outages will always be our first priority, but we otherwise prioritize fixing regressions over non-critical emergent issues.
This is a pretty clear regression in behavior that I anticipate will be addressed shortly, but I can't make any promises!
Thanks for the post reply. I'm not using S3 so, unfortunately, this won't work for me.
The filename issue is still present and it does slow down our users by 30 seconds or so per item.
Looking forward to a fix being published.
Great suggestion, @Priyank_Jain! Where are your files currently being stored, @Paull? I would love to explore a similar approach, if possible, that would be a serviceable workaround until we address the underlying behavior.
@Darren thanks for the reply. We are currently using retool storage as a temporary solution until we can hook up dropbox to seamlessly store files.
So, our pdf viewer is displaying the file from retool storage, however, when I download, it uses the hash name, not the filename. I have to navigate to retool storage in a separate tab, then download the file from there, to maintain the filename.
Note that there's a little bit of weirdness if you've set up a custom domain, which is why the code snippet inside the component inspector isn't just getFileData.data.url. Additionally, this does require that you define a separate query to retrieve your file from Retool Storage, but it sounds like you'll need to do this anyway once you integrate Dropbox.
@Darren thanks for the reply.
In my case, the PDF is generated by a workflow and the return data is the file id.
I pass this id into a global variable, so the PDF viewer will work anywhere in the app as long as the variable is updated.
I was able to use this global variable in the URL instead of adding the getFileData query: https://myname.retool.com/api/file/{{ var_pdf_viewer_file_id.value }}
When we hook up dropbox, I'm sure we'll be able to use the return data from the api to update the PDF viewer, as long as we switch all the storage at the same time!
Thanks for your help. @Priyank_Jain thank you for suggesting using the URL, I think you opened the door to a different perspective, which was needed.
I would be interested to see if anyone else is affected by this.
Instead of using the 