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!