LeeAnne,
Can I assume from this post that PDF will never be coming back to not
requiring a download?
I wouldn't assume "never", but it probably won't be a priority and might end up as practically never unless he get's some push-back on the issue.
Mark's #changelog item didn't go into any detail about the nature of the vulnerability, or whether it can be resolved in a way that permits in-browser display of files, or at least certain types of files.
We have 9 pages of folders all of which contain at least one document
- many have sub folder and can contain several documents. These
documents are updated constantly (or should be darn it!) so a fresh
download is needed each time it is looked at.
One work-around that I think has been mentioned is to use the group's Wiki for those documents instead of Files. With so many files to switch over that wouldn't provide instant gratification, but you could spread out the effort by first creating a set of wiki pages that serve as a TOC or an index to the files, linking to them. But then each time a file needs to be updated, take that as the moment to re-write it as a wiki page; then update the TOC/index page to point to the new wiki page instead of the old file.
The payoff in the longer run is that Wiki pages are designed to updated by multiple users, and they let you keep track of and manage the updates. The ease of updating them may encourage more timely updates.
A downside is that the formatting available in the Wiki editor is not as flexible as features you may have used in Word or other tools you have been using to create those PDF files. So the Wiki approach may not work very well for documents with more than just basic formatting.
Another downside is that the Wiki doesn't present a nested folder view of the pages comparable to the folder structure for files. Instead you must manually organize them using pages of links (as I've done in GMF's Wiki).
Shal
Shal Farley