Changes to moving content in Confluence Cloud

[#1]

Update (March 26, 2024): The team has been hard at work over the past quarter making architectural changes to the page move feature. As a result, we've raised the limit to 1000 pages per move operation!

---

Hello Confluence Admins,

We’re writing to explain a change to content move operations in Confluence, arising from an investigation on reliability of bulk moves. Moving forward, we will enforce a 100 item limit per move operation to ensure a performant and reliable experience. Very few users ever move more than 100 pages at once, and we anticipate that this change will impact less than 1% of moves. Additionally, once this change is made, users will still be able to move more than 100 pages via separate move operations.

We will begin incremental rollout of this change on December 14, 2023.

Rationale for change

Without limits on the number of items moved, we’ve encountered

• Slow failures: When the move operation gets to be larger than 100 pages, both reliability and latency drop below our quality bar.

• Data corruption: When a large volume of content is moved, we’ve observed a risk of failure that leave data in a corrupted or incompletely moved state. Some pages moved successfully, while others failed, which causes users to worry that their content has been lost.

• Load on system impacts other users: When large page move operations are triggered, all users on shared infrastructure take a performance hit. For example, unlimited size means someone testing an app for load limits might inadvertently cause your access to be slowed.

In determining a hard limit, we considered what is necessary to mitigate the above issues while minimizing breaking changes for our users. Over 99% of page moves are 100 pages or fewer, so this change should not impact most users.

Next steps

In order to support larger moves with high reliability, we need to invest in an architectural redesign of the feature. From a technical perspective, this could include asynchronous handling of the page move operation. Today, the move request is run synchronously, which can affect the load of shared resources.

This investment is not on the near term roadmap, but to elevate the priority on supporting larger content moves, engage (vote/comment/follow) on this feature request: CONFCLOUD-77144

[chihara]

@Nick Bourlier 

Do you make clear that what "item" mean? (page, attachment, macro...)

[Nick Bourlier]

@chihara "item" is just a piece of content that appears in the page tree in the left sidebar. So pages would fall into that category, but not attachments and macros at this point.

[chihara]

Thank you.

[Chihara]

@Nick Bourlier 

One more question. 

If user attempt to copy pages >100,  are there any warning popup/message or aything to users? 

[Kristján Geir Mathiesen]

Hi @Nick Bourlier and thank you for informing us. 

Not sure I am terribly happy with this change since I am one of those 1% of users trying to move more than 100 pages... but I guess we don´t get all the things we want in life :)

[Michael Woffenden]

One of the 1% and not at all happy with this limitation.

Can we get a fix soon?

[John Fox]

I can understand the need to make this cleaner and safer. They way it worked before usually worked with large moves, but did seem to be unstable - I generally crossed my fingers and waited and hoped it would all come forward.

However, there has to be a more user-friendly solution than simply capping at 100 pages. I have a need to move very large trees of pages. Keeping the tree hierarchy intact is nearly impossible with the way this is working now.

How about allowing me to move a page with more than 100 children but only move the first 100 children, leaving the rest behind? That would make it WAY easier to keep the hierarchy intact.

The way things are working now is a MAJOR burden for my needs.

[John Fox]

You have to at least add a way to move the parent page first without the children (if it has more than 100 children). Trying to move a 2,000 page tree from the bottom up is nearly impossible. Can someone please help with this?

[Michael Aglas]

So Atlassian has a problem. And they are not able to fix it (or just don't want to), for whatever reason. So they checked that it is a rare occurance (that we need to believe) and decided not to fix their problem, but instead make the problem a user problem by limiting the number of pages... that's odd

One question: Am I able to add more than 100 pages below a page? This should then be restricted as well, shouldn't it?

So we have a very well documenation set up and have now the problem to just move it below another page and can't do it... Even if I try to move pages some level down, I still get the error. So what is the solution here? Looking for an alternative to Confluence? Well, goal achieved I would say.

Atlassian get your tools clear!!!

[Michael Aglas]

And why 100 pages? That's not even quite an unusual high number of pages...

[Glenn Morrow]

Yea. Not good. In many cases the moving of 100+ pages may indeed be in the 1% - but I think its more likely 100% users will need to move more than 1% sometimes. And is indicated by others this current configuration does not allow for any user-friendly work around of 100+ page trees. One of the beauties of Confluence On-Prem was the way you could move things around - even move sections to a completely other space - and not break anything. It just worked. ALSO this is super bad timing with the server products expiring now so many migrations are happening at this time ... when people are going to want to move 100+ sections the most! We don't need a user-friendly drag-and-drop real time feature, but we do need a feature - can be as clunky as you like, run as a back-ground task if you like, just something that'll work for those use cases when you do want to move 100+ sections. :( 

[Kunal Desai]

@Nick Bourlier , right now the issue with Copy function I've found is - when you Copy page from one space to another it won't retain the page metadata. So, the page in its source location will have history when page was created, who is the owner, tracks updates made by user, version control and date timestamp and allows you capability to restore from specific version.  But this information is lost with Copy, and it creates brand new object in target location and now it is showing me as the owner who just created a page. How can I resolve this and workout for it?

However, with Move function this is not the case.  

[Glenn Morrow]

It gets worse. You cannot even re-sort pages under the same parent for the same reason (if exceeds 100 children). Argggh. 

@Nick Bourlier I have seen many comments over the years when people get all up and antsy about some small bug or missing feature and get down on Atlassian for it when they really don't comprehend the scope of the product or how much work each of these small things can be. I always roll my eyes. But this time I am becoming one of those persons! As a long-time Atlassian fanboy I have to say I think this is a serious mistake! One of the things we love about Confluence is the flexibility. Make your content in one place, reorganise it at will, move it around, drop it into other spaces - nothing seems to break. It is this flexibility and confidence that Confluence won't break things that endears (or endeared) us to it. Now this flexibility has gone. I am afraid 100 child pages is nothing. Because another great thing about Confluence is (was?) that you can use a deep "page/sub-page" structure or a "flat-folder" structure with labels, or both - whatever you want as much as you want. This 100 page move limit really puts a damper on that. I think actually limiting to child 100 pages or even less is a great idea for stopping accidental move and destroy of vast amounts of your content - I'm all for locking it down even a little more BUT with the option to unlock as needed (even if you have to choose from a 100/500/1000/unlimited limit - with some caveats or the content gets locked as uneditable while it moves or whatever ... I do understand unlimited move capability impacts (especially if it was in error and they just move it back again right away!) but some locking mechanism so people only do it when they have to or whatever would be fine - as long as you don't totally remove this key aspect of Confluence.

I am mid migrating several spaces form on-prem to cloud and not being able to reorganise and manage them once migrated is ... a problem. I don't see how you'd get me some solution for this in the timeframe I need it even if you wanted to now but at least if this could be reviewed and resolved for the future then I could put my fanboy badge back on with pride. Lol.

Glenn

[alexey_papkovskiy]

Hi, we are using Sphinx Confluence Builder and it uploads more than 100 pages at once, and it seems there is no good solution. Could you give a tip on the possible workaround?
Could be the option confluence_cleanup_purge the cause?

[Glenn Morrow]

But wait there's more - you can't even delete a page with 100+ documents under that one page. But that's the whole point of a "flat file" system and using labels - for those who want to organise things like that. Atlassian you have crippled your product in so many ways with this. :(

[Steven Rhodes]

So there is a wound with blood coming out of it. Atlassian's fix is to put a bandage on it instead of fixing the internal bleeding. Then call the removal of the bandage a "feature request". See CONFCLOUD-73514 and CONFCLOUD-76077 for the bugs which have now been closed. 

Why even allow > 100 child pages if you can't move them? Is there a structured < 100 page workaround for this in sections?

[Glenn Morrow]

https://jira.atlassian.com/browse/CONFCLOUD-73514 "When you have a parent page with over 2,500 children pages ..." 

Um, 2.5k is not the same as 100! Doh. In one of my comments about I suggested maybe 1000 page limit rather than 100. I was surprisingly not far off. I am sure in most cases 1000 child pages would cover it or least you could then move in chunks of 1000 without too much trouble - unless you are a 100,000 page site? Which is why it still needs an override option of some sort to cover those use cases too.

But seriously - 2500 is not 100.

[Michael Woffenden]

Great news!  Thanks to the Atlassian team for raising the limit to 1000.

[Glenn Morrow]

Oh really? Nice! That is gonna help a lot. Go team. :)