Thank you for raising this issue. While we can see how this feature would be useful, we have no plans to implement it in the foreseeable future. In order to set expectations, we're closing this request now.

Thanks again for your idea.

Bill Arconati,
Confluence Group Product Manager

CONF-14131 covers the issue with the URL, and I see that you have voted for that issue, and I see that you've already pasted the above comment to CONF-3079, which requests the ability to delete individual versions of attachments.

The following comments are from a separate job that we lodged. In response, we were referred to this existing job. Unlike the poster above, we don't consider this to be a "minor" feature, for reasons which were explained in our support request.

----start-of-copy/paste----
We use Confluence for our organisation's public web site, as well as for our internal documentation.

Although we try and maintain as much of our content as possible in Wiki Markup or within

macros in Confuence web pages, there are some things for which we need to use documents, which we have done by means of attachments to confluence pages. As you might expect, this tends to be in the form of PDF files, and Word, Excel and Powerpoint documents.

Periodically we need to update these documents, and when we do so Confluence maintains a version history, instead of just replacing the file. This strikes us as being a good thing for a Content Management System to do.

When the wiki markup on the confluence page is turned into HTML, the attachments end up as links which look like:
http://www.nameoforganisation/download/attachments/PAGEID/NameofFile.doc?version=x

We would like to raise a couple of issues arising from this:

(1) Because the version number is included as part of the link, people who bookmark the document/attachment links inadvertently will never see newer versions of the document.

In some circumstances, this might be a small inconvenience. However in other cases, it can be quite serious. We had a document which contained requirements for our students. These changed in important ways, so the document was updated and the new version uploaded. However some people had the old version bookmarked, and made the case that they had in fact done exactly what a document on our site said they had to...

(2) The presence of the "?version=x" string in the URL makes it obvious to even unsophisticated users that they can see any or all of the previous versions. Depending on the nature of the information which has changed, this can be embarassing or problematic.

We believe that it is reasonable to expect that once a document has been updated, that the CMS would prevent the previous versions from being generally available, or perhaps would only be available to people with privileges.

...
We believe that the best way to fix the underlying problem would be to augment the Edit Page's Attachment interface to allow old version(s) of files to be explicitly deleted. This gives people the option to do this if it is required. It might also be useful to consider whether or not to add a per-space setting which controls whether or not attachments are version controlled, or whether they are simply overwritten...
----end-of-copy/paste----

The feature which this job (CONF-1978) suggests would also address the problem. However this ticket has currently been untouched for 4 years, 4 weeks and 4 days, then this looks unlikely to happen any time soon. I have to say that having plaintive requests for features just left orphaned like this, for years and years, really does not do anything positive in the minds of your paying customers.

Andy Jones

Understood on the fine-grained permission. What about a broader space permission that includes the ability to view page history and attachment history? Call it a 'historical view' permission.

I wouldn't mind updating the title of this issue to reflect that possible functionality.

Also, I would prefer this be downgraded to a Minor feature. Just something that would be nice to have. Thanks.

Ruben,
Well, it's of course possible to code; it's just a very fine-grained permission. I guess it depends on the popularity of the request to implement it.

Cheers,
Nick