• We collect Confluence feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

      NOTE: This suggestion is for Confluence Server. Using Confluence Cloud? See the corresponding suggestion.

      Any way permissions can be configured to not allow folks to view previous versions of attachments?

      One way, and they way we'd prefer, would be to only allow them to view the current version if they have just View permissions in that space. I suppose another way would be to add a permission for "Version Tree" in Attachments (next to Create & Remove) or something similar.

            [CONFSERVER-1978] Ability to lock the version tree on attachments.

            BillA added a comment -

            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

            BillA added a comment - 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.

            Don Willis added a comment - 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

            {HTML}

            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

            UQ Business School added a comment - 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 {HTML} 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 Miranda added a comment - 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

            Nick Faiz [OLD] (Inactive) added a comment - 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

              Unassigned Unassigned
              ff865951a3af Ruben Miranda
              Votes:
              1 Vote for this issue
              Watchers:
              1 Start watching this issue

                Created:
                Updated:
                Resolved: