Since Confluence lacks a native translation tool, this has become a major issue for us. The high number of attachments poses a significant limitation with every translation tool we've attempted to use.

The workaround will not work for us as it's completely functionally different - you cannot update existing pages using the hierarchy copy, which is a core feature of our use case, and you additionally do not receive information about the created page, another core requirement of our use case. Due to these limitations, and the nature of the endpoints actually being quite different, I'm not sure that the workaround can really be labeled as a workaround.

Hello,

The endpoint also returns 504 on pages with 200 attachments and there isn't a homogenous error response. We get an Internal server error as a message and sometimes an HTML format as a message with the title Something went wrong and body We're moving mountains to get it sorted.

The workaround does not help in our case (Comala Publishing Cloud), since we need some functionality of the affected endpoint, like the destination params. With the workaround endpoint you can not copy a page in a specific space as a root page, only accept copying the page in an existing page ID (destinationPageId) and you can not replace the content page on an existing page, if the page already exists the endpoint returns a 400 status with message com.atlassian.confluence.api.service.exceptions.BadRequestException: The copied content tree has conflicting titles. Please specify a title prefix to avoid conflict.{}

Since more of our clients are migrating from server to cloud, we are having more support tickets related to this problem. The problem dates back to last year and has still not been solved. Please, reconsider the priority of this issue or give us a workaround that could fit our case when you need the same functionality of the affected endpoint.

Thanks.

The large attachment count has become a limitation in all of the translation tools I've tried to adopt. We cannot localize our documentation because the translation tools timeout before we can get the translation completed. Please re-prioritize this issue. 

This is causing a significant impact on the team approaching a deadline.  I'm currently refactoring the page for one of the engineers (due to timescales) and having to manually manage all the attachments is a really bad user experience.

Hello,

This issue cost me several week of delay in getting my Confluence [Product]Manual to produce a Scroll Document Version to publish to our online Help Centers (several weeks after the Prod version of the Product was released) .

At first I opened a Support ticket with Confluence and the support guy closed the ticket insisting this was not a Confluence issue but rather a "3rd Party product issue" (i.e., Scroll Doc /K15t Support issue). I was not impressed as up to this point I have enjoyed excellent support from Atlassian. 

Scroll / K15t Support were much more diligent in helping me and directed me to look at the 1st Page (I call it the manual title page) “Attachments”. There were 299 “Attachments” (but there were actually no images on this title page). Then he directed me to install another 3rd party product called “Attachment Manager”. 

Once I quickly got rid of the 299 “unused” attachments on my Manual Title Page with Attachment Manager I was able to successfully create a new Scroll Doc version.

I’m not thrilled that we have to buy this “Attachments Manager” to fix what seems to be a Confluence bug or at least attachment management shortcoming - that's why I'm casting my vote on this  CONFCLOUD-75318- Copy REST API returns 504 for pages with many attachments) issue.

Please bump up the priority of this issue.

Also, please advise the Confluence Support Team about this issue & this workaround “Attachment Manager” so others won't be impeded by this issue. https://marketplace.atlassian.com/apps/1222381/attachments-manager-for-confluence?hosting=cloud&tab=overview

Thanks

Kind Regards,

Sheila Glass

Hi team, please reconsider the priority of this issue. Before, on Server, we used to have most of our attachments under the space's Attachments directory. This directory has been moved to our space's root page in Cloud. So now we ended up with one page having over 4000 attachments in each version.

In our company we use Scroll Documents to manage the versions of our documentation on the Cloud. Because of this bug, the said page cannot be copied and hence, we cannot create a new version of our documentation. 

This is a huge blocker. Because of this we cannot publish our documentation to our customers as we cannot have new versions.  And because of this we are still using Confluence Server whereas we were planning on going live with the Cloud version in July. 

As the Server support is approaching its end of life and we cannot switch to Cloud because of this bug, we seem to be stuck and that is why the resolution of this bug is essential to us.

@Damian thanks for finding this!

Hi all 👋 Also an important aspect to take into account is to allow users to discard attachments that are no longer used in the current version of the page. Let's say the page relies heavily on images and since its creation, 64 versions have been created. Each version has an average of 20 image changes. At version 65 you'll end up with a huge amount of attachments that might not need to be parsed or even copied over to the new page.