Uploaded image for project: 'Confluence Cloud'
  1. Confluence Cloud
  2. CONFCLOUD-71292

Copy single page API with custom body does not work anymore

    XMLWordPrintable

Details

    Description

      Issue Summary

      Marketplace Partner reported issue on the Developer Community https://community.developer.atlassian.com/t/copy-single-page-api-with-custom-body-does-not-work-anymore/43714

      We are experiencing a major problem with the Copy single page API. One of the core features of our app (Scroll Documents) is to create copies of pages (or rather page trees) where include macros are resolved, so the macros are replaced by the actual content of the included page, and any attachments referenced by the included page are copied over.

      Steps to Reproduce

      Imagine you have a Page A and a Page B. Page A contains an include macro that includes page B. Now you want to create a copy of Page A (called Page A*) where the include macro is resolved. The way our app does this is:

      1. Fetch Page A, parse the storage format and look for include macros
      2. Discover the include macro pointing to Page B, so fetch Page B and replace the macro with the body of page B in the parsed body of Page A
      3. Now copy Page A to Page A* by using the Copy single page API (using a parent_page destination). Specify the parsed body of Page A with the replaced include macro as a custom body during the copy operation.
      4. Look at the body of Page B and see if it references any attachments attached to itself. If it does, use the Copy single page API with an existing_page target to copy Page B to Page A*, with copyAttachments: true and specifying the body of Page A* as a custom body for the copy operation. This will copy all attachments of Page B to Page A* (which is needed because they are referenced in the included content), without changing the body of Page A*.

      While this definitely worked back when I was developing this feature, we just discovered by accident that step 3 doesn’t work anymore as intended. I don’t know for how long this has been the case, but I hope for not too long, because this breaks one of the core features of our app without being immediately noticeable (because include macros are not identifiable when viewing the page).

       

      For reference, here are the two exact requests that we are doing:

       

      {{}}

      
      

      POST https://cdauth.atlassian.net/wiki/rest/api/content/1182859265/copy?expand=children.attachment.version%2Cbody.storage%2Cmetadata.properties.K15tDocsPage%2Cversion%2Cspace
      {{ }}
      {{{ "copyAttachments" : true, "copyPermissions" : false, "copyProperties" : false, "copyLabels" : true, "copyCustomContents" : false, "destination" :

      { "type" : "parent_page", "value" : "1185349633" }

      , "pageTitle" : "(v24) Include test", "body" : { "storage" :

      { "value" : "<p>Test content 1</p>", "representation" : "storage" }

      , "raw" : null } } }}

       

       

      {{}}

      
      

      {{POST https://cdauth.atlassian.net/wiki/rest/api/content/1179582465/copy?expand=children.attachment.version%2Cbody.storage%2Cmetadata.properties.K15tDocsPage%2Cversion%2Cspace }}

      {{{ "copyAttachments" : true, "copyPermissions" : false, "copyProperties" : false, "copyLabels" : false, "copyCustomContents" : false, "destination" :

      { "type" : "existing_page", "value" : "2023293113" }

      , "pageTitle" : "(v24) Include test", "body" : { "storage" :

      { "value" : "<p>Test content 2</p>", "representation" : "storage" }

      , "raw" : null } } }}

       

      Expected Results

      Page is copies completely

      Actual Results

      What seems to happen is that in step 3, when specifying a custom body using a parent_page copy destination, that custom body is ignored the the body of the target page is the same as the body of the source page. However, in step 4, when specifying a custom body using an existing_page copy destination, specifying the custom body seems to work.

       

      Workaround

      Currently there is no known workaround for this behavior. A workaround will be added here when available

      Attachments

        Issue Links

          Activity

            People

              etekin@atlassian.com Engin Tekin
              rwhitbeck Ralph Whitbeck (Inactive)
              Votes:
              8 Vote for this issue
              Watchers:
              9 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: