Uploaded image for project: 'Confluence Data Center'
  1. Confluence Data Center
  2. CONFSERVER-996

Allow removal of page version history for Space Administrators

XMLWordPrintable

    • 13
    • 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.

      Atlassian Status as of January 8, 2013

      Thank you to everyone for your suggestions and feedback on this issue. Based on customer conversations and comments on this ticket, the most prevalent need in this area is the to manually remove specific versions of a page for the purposes of removing confidential information (e.g. passwords). Therefore, in the next version (Confluence 5.0) we plan to provide the ability for space administrators to manually remove specific versions of a page. We will mark this feature as closed once we ship 5.0.

      There have been a number of comments requesting additional functionality beyond this for the purposes of minimizing database storage requirements or for adhering to content retention requirements. We have opened another JIRA issue for this use case which can be found at CONF-27701.

      Thanks again for your comments and contributions.

      There are several reasons why it would be useful to be able to remove historical versions of selected pages:

      • to remove confidential information which was accidentally added while editing the page
      • to reduce the database usage of Confluence, particularly on frequently- or automatically-updated pages
      • to comply with legislative document destruction requirements (e.g. delete content older than some years).

      Practically speaking, this might be implemented in a number of different ways:

      • ability to remove old versions of pages older than specific date (e.g. get rid of anything older than 6 months)
      • ability to limit the number of old versions kept (e.g. limit to 5 previous versions)
      • ability to remove specific old versions from one or more pages.

      These tasks could be done manually via space admin, triggered by an automatic housekeeping task, or done manually for specific pages.

        1. Screen Shot 2011-11-23 at 7.56.01 AM.png
          Screen Shot 2011-11-23 at 7.56.01 AM.png
          136 kB
        2. Screen Shot 2011-11-23 at 8.06.01 AM.png
          Screen Shot 2011-11-23 at 8.06.01 AM.png
          114 kB

          Form Name

            [CONFSERVER-996] Allow removal of page version history for Space Administrators

            Renan Battaglin added a comment -

            Hey everyone,

            A quick update and a request for help.

            We are very close to shipping a solution that would allow admins to set retention rules for page and attachment versions, and for automatically purging trash in Confluence.

            However, we need your help to validate the UI and refine how we communicate the options.

            We are planning to run a few user testing sessions over the next couple of weeks and would love if you could participate and give us your feedback.

            What's involved?

            • Sessions will be 45 minutes in length and conducted over video conference, with our team in Sydney.

            How do I participate?

            • We will confirm a few details before sending through a calendar invitation with video conference details
            • During the session, we will show you the UI for the feature we are planning to ship and ask you to complete a few tasks so we can learn about how easy the UI is to understand and what could be improved.
            • As a token of our appreciation, you'll receive a thank you gift following the completion of your session.

            We can't guarantee that we will be able to speak with all interested parties but we definitely appreciate your interest and enthusiasm to help us make Confluence easier and more enjoyable to use.

            Thanks,

            Renan | Product Manager, Confluence Server and Data Center

            Renan Battaglin added a comment - Hey everyone, A quick update and a request for help. We are very close to shipping a solution that would allow admins to set retention rules for page and attachment versions, and for automatically purging trash in Confluence. However, we need your help to validate the UI and refine how we communicate the options. We are planning to run a few user testing sessions over the next couple of weeks and would love if you could participate and give us your feedback. What's involved? Sessions will be 45 minutes in length and conducted over video conference, with our team in Sydney. How do I participate? If you're interested in speaking to us, please send us an email at rpit@atlassian.com We will confirm a few details before sending through a calendar invitation with video conference details During the session, we will show you the UI for the feature we are planning to ship and ask you to complete a few tasks so we can learn about how easy the UI is to understand and what could be improved. As a token of our appreciation, you'll receive a thank you gift following the completion of your session. We can't guarantee that we will be able to speak with all interested parties but we definitely appreciate your interest and enthusiasm to help us make Confluence easier and more enjoyable to use. Thanks, Renan | Product Manager, Confluence Server and Data Center

            Tobias added a comment -

            Hallo together, 

            interesting Task. We also need this feature asap. We have pages with over 2k versions. 

            To delete this manually is a job I don´t have time to. Pls release this feature in the next few LTS versions.

            Tobias added a comment - Hallo together,  interesting Task. We also need this feature asap. We have pages with over 2k versions.  To delete this manually is a job I don´t have time to. Pls release this feature in the next few LTS versions.

            Renan Battaglin added a comment -

            Hi all,

            Thank you for your votes and comments on your experience with page versions.

            The Confluence team is exploring technical and user experience improvements for page versions. We've received feedback on various aspects of this problem and would like to speak with Confluence Server/Data Center customers to better understand the concerns and problems.

            What's involved?

            • Sessions will be 45 minutes in length and conducted over video conference, with our team in Sydney.

            How do I participate?

            • We will confirm a few details before sending through a calendar invitation with video conference details
            • During the session, we'll start with a general chat to understand more about your role and your company, then dive deeper into your experience with the page versions - what's working well, what isn't working well and suggestions for improvement.
            • As a token of our appreciation, you'll receive a thank you gift following the completion of your session.

            We can't guarantee that we will be able to speak with all interested parties but we definitely appreciate your interest and enthusiasm to help us make Confluence easier and more enjoyable to use.

            Thanks,

            Renan | Product Manager, Confluence Server and Data Center

            Renan Battaglin added a comment - Hi all, Thank you for your votes and comments on your experience with page versions. The Confluence team is exploring technical and user experience improvements for page versions. We've received feedback on various aspects of this problem and would like to speak with Confluence Server/Data Center customers to better understand the concerns and problems. What's involved? Sessions will be 45 minutes in length and conducted over video conference, with our team in Sydney. How do I participate? If you're interested in speaking to us, please send me an email at rbattaglin@atlassian.com We will confirm a few details before sending through a calendar invitation with video conference details During the session, we'll start with a general chat to understand more about your role and your company, then dive deeper into your experience with the page versions - what's working well, what isn't working well and suggestions for improvement. As a token of our appreciation, you'll receive a thank you gift following the completion of your session. We can't guarantee that we will be able to speak with all interested parties but we definitely appreciate your interest and enthusiasm to help us make Confluence easier and more enjoyable to use. Thanks, Renan | Product Manager, Confluence Server and Data Center

            Kalas Richard added a comment -

            You can use this plug-in to remove all or selected page versions easily:

            https://marketplace.atlassian.com/plugins/com.elitesoftsp.confluence.page.utility.plugins/server/pricing

            Kalas Richard added a comment - You can use this plug-in to remove all or selected page versions easily: https://marketplace.atlassian.com/plugins/com.elitesoftsp.confluence.page.utility.plugins/server/pricing

            Midori added a comment -

            Just removing the a specific page from the history just wont cut it for me - I need to be able to remove ALL historic pages within a space either all before a date or keep just n version. With 6K pages and growing this is not a manual task (the rate of growth of page history during development of our documentation is enormous - some pages have 30 or 40 historic version most of which are totally irrelevant and just occupy DB space)

            @kevin.hughes, Archiving Plugin implements this functionality.

            You can configure it to automatically:

            • find all pages not updated for X days (or labelled with "expire-14/01/02")
            • find all pages not viewed for Y days
            • remove all pages not updated for Z days (or labelled with "archive")

            Remove is actually copying the page to a space in ARCHIVE status. It has the advantage that the page can be restored later (if needed), but it will totally disappear from searches, activity streams and so.

            As for the original feature request, the plugin does not offer a solution for individual page versions. It relies on the "last updated" and "last viewed" timestamps - and works with "whole" pages, consequently.

            See the user documentation for details.

            Midori added a comment - Just removing the a specific page from the history just wont cut it for me - I need to be able to remove ALL historic pages within a space either all before a date or keep just n version. With 6K pages and growing this is not a manual task (the rate of growth of page history during development of our documentation is enormous - some pages have 30 or 40 historic version most of which are totally irrelevant and just occupy DB space) @kevin.hughes, Archiving Plugin implements this functionality. You can configure it to automatically: find all pages not updated for X days (or labelled with "expire-14/01/02") find all pages not viewed for Y days remove all pages not updated for Z days (or labelled with "archive") Remove is actually copying the page to a space in ARCHIVE status . It has the advantage that the page can be restored later (if needed), but it will totally disappear from searches, activity streams and so. As for the original feature request, the plugin does not offer a solution for individual page versions. It relies on the "last updated" and "last viewed" timestamps - and works with "whole" pages, consequently. See the user documentation for details.

            Cedric Weber added a comment -

            mark.mielke yes, some exasperation in my comment - as I mentioned this concern earlier in my previous comment: https://jira.atlassian.com/browse/CONF-996?focusedCommentId=304010&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-304010.

            "Transparent" might be a wrong term, but what I expect is just simply to always maintain the version numbers and simply add "deleted by user USER on TIMESTAMP. DELETION COMMENT" to the pagehistory.

            Cedric Weber added a comment - mark.mielke yes, some exasperation in my comment - as I mentioned this concern earlier in my previous comment: https://jira.atlassian.com/browse/CONF-996?focusedCommentId=304010&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-304010 . "Transparent" might be a wrong term, but what I expect is just simply to always maintain the version numbers and simply add "deleted by user USER on TIMESTAMP. DELETION COMMENT" to the pagehistory.

            Paul Curren added a comment -

            kevin.hughes, this will be added to the remote API when CONF-28258 is implemented. It looks like this will now be in 5.0.3.

            Paul Curren added a comment - kevin.hughes , this will be added to the remote API when CONF-28258 is implemented. It looks like this will now be in 5.0.3.

            markmielke added a comment -

            Cedric is probably just speaking in exasperation.

            Delete can't be transparent. It's either changing history, or it's showing that the history was deleted. Neither is transparent. However, for certain aspects - such as being able to treat the "version number" as permanent history, I would have expected to be able to take that version number and try to access it, and for versions that exist, I would expect it to return the same content as it did before, and for versions that do not exist, I would expect it to send me to a page which tells me that the version was deleted by XXX on TIMESTAMP.

            I haven't tried this functionality myself yet. If the behaviour is as per above, I'm concerned too...

            That said - deleting a page doesn't really have an audit trail either in my experience, and the use cases for deleting versions are such that we often don't need the history (otherwise why would it be safe to remove the content in the first place?), so from this perspective, for it to re-number and/or not record the audit details isn't so bad.

            I do wish that deleting a page and deleting a version both had audit trails. This might be a feature request.

            markmielke added a comment - Cedric is probably just speaking in exasperation. Delete can't be transparent. It's either changing history, or it's showing that the history was deleted. Neither is transparent. However, for certain aspects - such as being able to treat the "version number" as permanent history, I would have expected to be able to take that version number and try to access it, and for versions that exist, I would expect it to return the same content as it did before, and for versions that do not exist, I would expect it to send me to a page which tells me that the version was deleted by XXX on TIMESTAMP. I haven't tried this functionality myself yet. If the behaviour is as per above, I'm concerned too... That said - deleting a page doesn't really have an audit trail either in my experience, and the use cases for deleting versions are such that we often don't need the history (otherwise why would it be safe to remove the content in the first place?), so from this perspective, for it to re-number and/or not record the audit details isn't so bad. I do wish that deleting a page and deleting a version both had audit trails. This might be a feature request.

            Kevin Hughes added a comment -

            I agree with Cedric regarding the audit log - Enterprise software should log all such changes to an audit log but then again there is no audit log for other actions (or is there????)

            I dont think the versions should be renumbered after a deletion - surely the fact that a historic version has been removed needs to be obvious. HOWEVER doesnt that contradict the expectation that deletions are transaprent as renumbering makes it exactly that? Perhpas I am miss undertanding?

            Kevin Hughes added a comment - I agree with Cedric regarding the audit log - Enterprise software should log all such changes to an audit log but then again there is no audit log for other actions (or is there????) I dont think the versions should be renumbered after a deletion - surely the fact that a historic version has been removed needs to be obvious. HOWEVER doesnt that contradict the expectation that deletions are transaprent as renumbering makes it exactly that? Perhpas I am miss undertanding?

            Cedric Weber added a comment -

            If I delete a historic version of a document it just disappears!? Without leaving any notice about who deleted this and when!? And versions are re-numbered!? IMHO this is a huge FAIL when implementing such a feature in a so called "Wiki"! What about the audit logging!?

            I expect the deletion of a historic version to be transparent to everybody!

            Cedric Weber added a comment - If I delete a historic version of a document it just disappears!? Without leaving any notice about who deleted this and when!? And versions are re-numbered!? IMHO this is a huge FAIL when implementing such a feature in a so called "Wiki"! What about the audit logging!? I expect the deletion of a historic version to be transparent to everybody!

              onevalainen Olli Nevalainen
              6db1c9425381 Reaktor
              Votes:
              253 Vote for this issue
              Watchers:
              165 Start watching this issue

                Created:
                Updated:
                Resolved: