Dear Customers,

I'm closing this ticket down as this feature was implemented in Confluence DC 7.16, as mentioned above the release notes are here, apologies for leaving this ticket open. The feature was implemented to be configurable on a site-wide basis, or a space wide basis, but not specifically on a per-page level. Here's the full documentation for how this feature works if you wish to explore further.

Thanks to all those who waited for this feature, I hope you find it useful when administrating Confluence DC, cheers!

Michael Andreacchio

Confluence DC Product Management

672f90c65081 and 5717f2a94c18, you may be interested in this if you haven't found it already:

• Confluence 7.16 Release Notes: Clean up historical data automatically

rbattaglin are there any updates to this? 
What are the major results of the user sessions? 

Thank you in advance. 

Very valuable feature! Are there any news when this will be released?

Are there some news when this will be released? 

If you want to delete page versions, you can use this app: https://marketplace.atlassian.com/apps/1215094/page-assistant?hosting=server&tab=overview

ScriptRunner is expensive. Has anyone found a cheaper solution?

Because there are workarounds, including a well done set of Built-in scripts by the Script Runner folks, I imagine that Atlassian is putting their developer time to other use in the core product.

It is frustrating to feel ignored; to believe that Atlassian is ignoring us. But slamming on them doesn't help. If it does anything, it irritates the people we need to help us.

Read the tickets carefully, search for an alternative, look for a workaround, come post them here. Lot's of people do that already - good on you.

@Atlassian - are you guys just gonna ignore this forever?

It looks like Atlassian is never track such issues and there is deal with add-on developers. Otherwise I don't understand what is the real problem here.

The ability to set a limit on number of versions stored is a safety feature that is badly needed. Confluence allows more versions than it can really support. When versions get up into the thousands it can become impossible to purge an item from the trash. For lower but still large numbers you can get errors in the log that raise worries about data corruption.

We're having to do regular monitoring queries and manual cleanup on problem cases to try to prevent the issues that happen when versions build up too high. If Confluence is not going to support very large numbers of versions, it shouldn't allow them.

Hello,

Is there any plan to actually implement this? This request is opened for more than 7 years and there is no other update since 2018.
For large scale Confluence sites this feature is a must as we have pages with more than 1000 versions and we do not need to store all of them and it is almost impossible to trim down these versions manually.

Regards,
Victor

As a developer and a system admin for a very large instance, I'd encourage you all to consider Adaptavist's ScriptRunner plugin. It does have a way to trim page versions in its Jobs tab, so that it can be a scheduled task. the issue you might face (as I do)  is that the process honors permissions, which means that even 'confluence-administrator' id's will need permissions for some pages. Still, its a lot better than the alternative. I have systematically trimmed more than 1000 pages (of my 350k+ pages) to more reasonable number of page versions (several with 5k+ page versions). If does take time, so having a SQL script to identify the pageIds and their spacekeys is most helpful to chip away at this, little my little. (Note: when it doesn't look like its working, its most likely a permissions issue) 

We are also interested in a limitation of versions.
But we want to set a difference-measurement like: hold versions with different content greater than 20% and drop versions >10% or similar.

In some caseses there are only letter changes and it produces a huge version historie. In some cases the whole content is changed and after 20 corrections at some words the last big change can't be undone.

How to DISABLE Page History and Page Comparision Views at the Server Version? -» No Add-On found to disable this (...)

We simply don't need a version history (with the versions of a page changed in the past), because we only use Confluence server for an internal WIKI and only the storage of the changes inflates the data directory, which is unnecessary for us.

Thx.

We could also really use this feature. Our users do not have access to the command line so that route is not an option.

@Tibor what?  The solution is a plug in?  This is so clearly a core JIRA need.

@Mark common, we do not want to spend money for plugins as this should be native feature of confluence itself. Or lower prices for plugins, then we will start thinking.

Pranjal and Tibor,

Did you see my comment on the 21st June last year about our paid add-on ScriptRunner for Confluence that will let you do exactly what you are seeking. 

The example in the comment shows how to take control of pages in a space (HR) and keep just 3 revisions and remove all revisions older than 90 days. This can be done automatically or as a one off script.

I hope that helps.

hey, we also need this feature. we have pages with 800+ revisions and it's nightmare to delete them, even they changed name during history. we need to have ability to delete all version history for page and for all pages in space at one click

Any update on this @Atlassian.

Has anybody written any macro for the same?

It will be good to just add "Select all" button in Page History so you'll be able to uncheck few last versions and delete all others.

It's curious how it's expected for customer to delete hundreds or thousands versions for hundreds or thousands unique pages?

This is must have option.

We've just released a new add-on in the Atlassian Marketplace called ScriptRunner for Confluence that allows you to prune the page versions (just like this issue).

We have included an example in our documentation of how you can use a scripted job to prune old page versions.
Our example shows how you can use CQL to specify the set of pages you want to "prune" and the number of versions you want to keep (3) and the age (in days - 90). Here's a screenshot:

This currently only works for blog posts, pages but we'll look to support attachments soon.
Note: the most recent version will never be deleted.

@Debbie,

That's too bad. Just for the record I'm a "Space Administrator" but not a System Administrator, which means that I can access the folders using Web Dav and setting up the CLI wasn't a problem, but I can't install plugins for example, which makes things difficult for me in that way.

So for example under the "Browse" menu I have "Space Admin", But I don't have some of the system administrator menus I read about here and there.

@Jeffrey Burr

Thanks for your quick reply. I really appreciate the idea and can see how this would work well. Unfortunately, due to my access level, I'm not able to access the CLI command line nor the "folders" (file side) of my space therefore this does not appear to be a solution that I can implement. Not being a System Admin means I'm very limited as to how I can manage my space...I'm limited to the "Space Tools" offered.

<<Reposted under different ID....>>

I'd like to offer some views from a Space Admin versus full System Admin on this topic....

As a Space Admin, there are specific versions of pages that I like to keep as "release versions" so that I can roll back to a set point of time. I'd like to be able to Name those versions and lock them so they could not be removed until a set time or event, like a new release, occurs. Therefore, "removing all versions > 5" scares me if it was done across the board on all spaces. I would hope this would not be applied without regard to which Space or Page is limited.

1. What I'd love to see on the "History Removal Page" is a way to select the pages that I want to remove and then click a "remove all selected" option so I CAN remove more than a single page at a time. This would also help many others here that want/need to do more than one at a time. Seems a very simple option to add--so maybe that's a way to get some relief for those with many pages to remove. I agree it does not automate the work, but it would help speed up the work. While I'm not worried about the server crashing while I'm doing updates on a page, some work on overall navigation requires me to Save the page to see the results...so the Preview option isn't possible and I end up with many pages in history that I manually have to remove (which I try to do at the end of each editing session). If there were a limited number of iterations allowed for the page (set by a Sys Admin), I'd lose my starting point for the day quickly and that would be very unappealing for me.

2. As I mentioned above, it would be great to have an option that would allow me to "Name" the versions so I can easily remember which one(s) I need to keep for rollback purposes. This would allow me to quickly find historical pages have meaning and which do not.

3. In addition, being able to "flag" a version so it would not be removed by an automated "clean up" process would also be helpful. A variant on this would be to flag the item for retention until a certain date or event is met. For auditing, that should mean that the Space Admin is on the hook for explaining why the item needs to be retained and not the System Admin. Give the Space Admin a way to list out all pages that are "flagged" and their "expiration dates" so they can effectively manage their space.

4. It seems that the limit setting should have options for "all pages in a space" as well as "specific pages in a space". Maybe a default could be set on each Page and then the owner of the page could reset it as needed for the purpose of the page. Doing this globally is not something that I'd like my Sys Admin to do without me having a way to limit the impact to my pages. While I understand completely the need to keep the system stable and meet legal requirements, doing so should include consideration of how each space needs to be managed. Space Admins should also have the same tools available to keep their own spaces cleaned. Please allow the limit tools to be used by Space Admins as well.

5. I do agree that there should be a "destroy" option as well as a "remove" option for pages that need to be removed permanently. This would be useful for cases where passwords or other sensitive info was in a page and that page needs to be shredded.

Thanks for your consideration.

@Debbie Hutcherson (moved below)

Interesting points. I don't know if this would be useful for you as a workaround but what I've been doing is backing up the page folder to a local folder that I have under version control in SVN.

That way I can back up only at selected points, roughly like your idea of release versions or key versions, and commit those to SVN, so then I have a versioned history in SVN of only the page versions I want.

I have an ANT build file that copies the Confluence page folder to my backup folder, and a BAT file that runs both the ANT build and then an SVN command to commit to SVN, so the whole thing is pretty much automated. I run the BAT file after trimming the number of history files in Confluence using the CLI command I described above, so I don't end up backing up hundreds of files. If I run the backup fairly regularly however, especially when there are significant changes, then I have the previous versions in the SVN history.

I think the features you suggest would be good to have, but for whatever it's worth that's a workaround. It seemed a little complicated at first but actually I prefer having things in SVN now since I know it so well and can not only save key versions but notate them with comments and so on.

I would also love to see this enhancement, particularly to be able to limit the number of versions or remove versions as a regularly scheduled task. In the meantime I've found a workaround that others might find useful.

Some background: we publish directly into the Confluence file system using Web DAV, and we write and edit the pages externally and save source file versions in SVN. So don't need the Confluence page history versions beyond a couple of versions for convenience, for trying things out using the Confluence page UI edit feature.

After repeated publishing during development we've ended up with many hundreds of versions, which can actually slow down the access to the page folder in Confluence, in one case to the point where the folder wouldn't open at all.

In a bit of a panic to resolve that one, I discovered that I could use the Confluence CLI to go in and delete versions using a command. You can even tell it exactly how many versions to keep.

You can find documentation at Bob Swift's CLI site, but basically the command is:

--action removePageVersions --space "SPACENAME" --title "PAGETITLE" --limit 5

I've also now got a .bat file set up that gets a list of child pages for a given page, then runs the above command off of that list, pruning versions of hundreds of child pages all at once.

I can now run these .bat files on a regular basis and clean out versions, but it would be even easier to be able to just specify "Page Version Limit = 5" somewhere in Confluence, or, failing that, to set something to "Remove Versions > 5" on a regular basis.

Related to this feature request, here is a knowledge base article on how to remove all versions of a page How to remove the full history of a page using SQL.

@Elizabeth's workaround is fine unless there are link references to the page. Links that users have used to reference the page will not longer work with the copy unless you go in an manually set them up by viewing the links for the current page.

An easy work-around for this is to create a copy of the page and publish the copy. This creates a new page with only Version 1. Any attachments are versioned to 1 as well.

I would like to add a twist and a new feature request to this discussion: while deleting historical versions is definitely something admins and page authors should definitely be able to do - it is very surprising that this has not been possible!! - the first step should be to be able to control who gets to view histories.

You should in any case add a permission to Confluence so that admins can restrict access to history. In many if not most cases it is highly undesirable that any anonymous visitor can see all the historical edits of pages. All in all, typically only very few versions of pages are useful; most revisions are insignificant artifacts of the editing process and the history created is just dead weight and distracting, if not harmful.

We use automation to push data to wiki pages. As part of this automation, we can end up with many versions of the same page as the data changes. In a recent case, we had 59 versions. It is extremely painful to delete these versions one-by-one when they are not required. This issue is causing a large increase in our backup sizes, thus we need a way to easily remove obsolete versions.

Can this please get prioritized for a release this year.

Does Atlassian have any update on this? We need this, not only for space management and then savings of keeping the server updated to handle the larger sizes and backups, but also fro security purposes. To minimize the risk of unwanted content in history pages that you really cannot search, we want to delete history in specific spaces or all but the current to minimize the risk of unwanted information (e.g. passwords, PHI, etc.). It doesn't seem that Altassian is interested in scalability and security given how long such issues remain open.

I can top that, we have a API process that udpates 6000 pages daily, we have 6000 pages with 12,000 versions each. I would like a space or site level admin function to say "Limit versions to 10. Than a nightly clean up process or also by date, older than XX number of days

We had one team auto update a page multiple times a day and broke 6,000 versions last year. They no longer use Confluence that way.

Our highest offender currently is over 2,600 page versions. Our top ten are all over 900 page versions.

I might try this... I have one large space I export weekly to move to a external facing server, I want to see if this will help make the space smaller and speed up the process. Plus we can delete all the old junk
https://ecosystem.atlassian.net/wiki/display/CPSP/Confluence+Copy+Space+Plugin;jsessionid=C9704B831A339CCAE15B5B3986F0480A

Looks like this one is never going to get done, I now have space with 500-600 page versions on many pages, we need a automated way to clean this up. No human will ever go back to Version 4 when they are on Verizon 664. It takes a looong time to export spaces and I'm sure it's making the database slower in some way,

Just wanted to provide more reasons why a automated solution is needed, we have 300 + spaces and a few we export weekly and migrate to a customer facing environment. In one case, we manually removed all old image versions and file versions and reduced the size of the space from 244 mg to 76mg. This greatly improved the import/export process.

The manual delete is a god start but for a enterprise solution, we need a automated process, something that runs nightly as a scheduled job and will remove all old version of content/files older than XX days. In my environment, we would run this nightly and delete old versions older than 30 days

Any news on this?

I agree with Kelly's comment "To be an enterprise solution, db management is critical", we have sox and reg controls that require data be removed after X number of days, months years. I would like a admin page or space level page where this can be controlled.

For us, this is not necessarily set max number of pages; if the page is associated with a ISO quality record, we must retain versions for 2 years. However, we want the ability to owners of their spaces and pages to be able to keep their version history cleaned up.

Yes, it would be nice to be able to do some bulk removals. But, I prefer to have the tools that identify the spaces and pages that are consuming the space to be able to communicate to authors to clean them up and authors also have the tools to remove their history.

We're having to add more heap space and allot more memory because of this issue and it can also start affecting performance at some point. Consider this is high priority so that consumers can stay with Confluence and expand to make it more enterprise-wide; not just for those that are starting to use in the last year or two. To be an enterprise solution, db management is critical.

A comment from Kevin Hughes on CONF-996 -

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????

@Bill – If the Service API provided space admins the ability to delete page versions, admins would have the flexibility to implement their specific companies' business rules.

For example: "keep the initial version, remove all revisions older than X days old, remove all revisions made by the same person on the same calendar day because they were clicking "save" every 5 minutes due to the fear the server would crash and take their beautifully crafted RTE page down in flames too."

Just being able to remove one version would be good enough for me, but there's no such functionality in OnDemand yet.

henrik242, we've implemented that in CONF-996. We plan to have it deployed to OnDemand by end of Feb.

Just being able to remove one version would be good enough for me, but there's no such functionality in OnDemand yet.

I agree with Hernik, allowing the remove of 1 version manually is a step in the right direction but for enterprise customers, we need the ability to limit the number of versions and delete versions older than X number of days, or X number of versions. It's a compliance issue, security concern and will also help reduce the amount of data in the DB. Our interal staff almost never use a version older than 1-2 ago. Look at the CONF-996 Issue, it's full of comments and requests for this https://jira.atlassian.com/browse/CONF-996