-
Suggestion
-
Resolution: Fixed
-
None
-
13
-
NOTE: This suggestion is for Confluence Cloud. Using Confluence Server? See the corresponding suggestion.
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.
- has a derivative of
-
- Gathering Interest
- is duplicated by
-
- Closed
- is related to
-
- Closed
-
- Closed
- relates to
-
- Closed
| Form Name | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
1.
|
Nominating for actual action. |
|
Closed | Unassigned |
[CONFCLOUD-996] Allow removal of page version history for Space Administrators
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.
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.
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.
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?
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!
Has this been added to the API? If so can you give me the interface as the docuemtnation may well be lagging
cheers
Kevin
Hi Kevin.
We'll be adding Remote API (XML-RPC and SOAP) support for removing individual version of pages in Confluence 5.0.1. (It may actually just miss 5.0.1 to be honest, but no later than 5.0.2).
See CONF-28258 for more details. I hope this helps you to manage your version histories while you wait for CONF-27701.
I remain greatly concerned about the indeterminate growth of the DB and my ability to control it. 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]
Will the ability to remove specific history pages be available via the RPC API????
Remove individual page version has been implemented in the most recent Confluence 5.0 Beta
@kevin.hughes, Archiving Plugin implements this functionality.
You can configure it to automatically:
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.