+1 

The way you used to be able to define how attachments appeared in the article was vastly better than the current attachment handling. That was a massive functionality diminishment.

Any traction on this from Atlassian, this has been a huge issue for our users and the download all option not so great.

The problem with the current preview is that it takes more effort to download the file file : one must click on the link for the preview, and then click on the tiny icon on the right hand side in order to download the file. Downloading is necessary when one wants to edit the file or simply print it correctly.

This Suggestion has been sitting around for so long, I had given up hope that Atlassian would ever pay it any attention.  But seeing that it has a status of "Gathering Interest," I'll add my vote in favor.  The suggested solutions include "Disable by User," but that would not be my preference. Read the cases in the comments: the problem is not one of personal preference, it is about the software behaving properly.

Typical installations involve the power users, who know how to control the software, and many non-power users, who just take whatever they get.  Requiring each user to take separate action will just result in a lot of frustrated non-power users, annoyed at how stupid the behavior is, but without the knowledge or time to fix it for themselves.

+1

The new preview is a step backwards and should be configurable.

@Atlassian: Does anybody really read and gather our concerns and problems?

We too would VERY MUCH LOVE to have a way to disable the universal preview( selectively by space or application, if possible).  We have a "process space repository" in which a large number of files  (docx, pdf, xlsx ) are attached to a page in the space which allows other documents and wiki pages to easily link to them ( we bypass the previewer by manually entering the url directly into the links).  Unfortunately, it appears that the universal preview essentially renders the SEARCH capability useless. If a search is made for a given filename, the search goes off to never-never land and can take up to 10 or 15 minutes  to return and open the file (in the previewer which we would have rather opened in the files native program in the first place). To make things worse ( and totally confusing),  about a minute or 2 into the search, the attachments page is displayed which leaves you staring at a totally unsorted list of files ...  I have been told the only solution is to break  the files up into  groups of 100 files or less per page, which is not really a viable solution for us.  I appologize for the length of this comment, but this issue has been frustrating us for over 2 years now... prior to the previewer, searches returned in less than 2 seconds!

Absolutely. I would like to suggest yet another solution: to have no preview at all. I would still prefer this over the current forced preview.

Thank you!

I'm responsible for a 10.000-User Confluence-Server Solution. Many Users asked me how to overule the Universal-Preview. Especially for Excel-Files it makes no sense, because Preview has no functionality, which is needed to use most of the Excel-Tables (filter, sort, expand, etc.).

In addition, Print- and Search-Functionality directly on Universal-Preview is requested by many Users, especially for PDF-Files.

I would love to see Deborah's suggestion in Jira some day - hopefully this ticket is seen by any Atlassian member.

Double-plus-good for Deborah Chandran's suggestion.  While more flexibility for the defaults would be nice, this really needs to be configurable at a per-object level.