Cannot edit pages created via copy single page API

I’d like to report a bug with pages created using the new copy single page API for confluence cloud. It was introduced here 10 days ago in this post, hoping that @rtalusan can chime in with a fix or clarification.

The copy single page API works as expected and I can view the copied page in confluence. The probem arises when I edit the copied page and try to publish changes, I get presented with a content cannot be accessed error.

I’ve tried several permutations of the API, I tried all varaints of the destination parameter and all the copy* parameters as well, but the copied pages all suffer the same problem. The copied page has no restrictions and the user I’m logged in as has permissions to edit the source page.

To recreate this bug use the following sample curl command to create a copy of a page such that the copy is a child of the original.

curl --request POST \
  --url '-url 'https://your-domain.atlassian.net/wiki/rest/api/content/{id}/copy' \
  --user 'user@example.com:user_api_token' \
  --header 'Accept: application/json;charset=UTF-8' \
  --header 'Content-Type: application/json' \
  --data '{
  "copyPermissions": true,
  "destination": {
    "type": "parent_page",
    "value": "{id}"
  }
}'

Now edit the copied page and publish changes, you’ll should be presented with a content cannot be accessed error.

2 Likes

Let me try to replicate this first.

@michael-k I am unable to replicate this error.

Steps I took to recreate:

  1. Created a page. Simple title and one line of text (similar to Ryan’s example in the Dev Chat video)
  2. Made the following call in Postman
    14

Which generates the following curl call (in case that’s easier to see):

curl --location --request POST 'https://<my-instance-name>.atlassian.net/wiki/rest/api/content/484933637/copy' \
--header 'Content-Type: application/json' \
--header 'Accept: application/json;charset=UTF-8' \
--header 'Authorization: Basic <my-bearer-token>' \
--data-raw '{
	"copyPermissions": true,
	"destination": {
		"type": "parent_page",
		"value": "484933637"
	}
}'
  1. Go back to confluence see my new page is a child of the original I copied.
  2. Edit (added another paragraph line of gibberish text)
  3. Publish (no errors)

Is there anything else specific about the page you can tell me? Specific permissions set on the page or higher up the hierarchy. Any attachments or content that might be special to consider?

@BobBergman / @TureHoefner I’m asking since you liked the original post.

Are you also running into this same issue and that’s the reason you liked the post?

@rwhitbeck thanks for trying to replicate the issue. I’ve dug into this some more and have a new insight.

So I have two confluence cloud sites one which has the problem and the other which doesn’t!

Site A is a development instance of confluence cloud which I created say 6 months ago. This site is experiencing the problem I described. The site has the “old” confluence navigation and home which is making me think it hasn’t been upgrade by the admins. I created the dev instance following a link on the developer getting started docs.

Site B is a freshly minted regular confluence cloud site created last week, and it doesn’t have the problem I described with copied pages. It has the ‘new’ navigation and home styles described in this post.

I’m developing a market place app that uses the new copy single page API and that’s why I was depending on the development instance. Shall I just ditch the development instance? Can I rely on users of my app having the newer confluence cloud sites where the pages created by the copy single page api can be edited?

Can you message me the instance url of the old development site you’re having the problems with.

My understanding is that all cloud instances got the API at the same time there wasn’t a progressive rollout of the API to instances as happens with new features.

@rwhitbeck sure, here is the site URL https://kate.atlassian.net/wiki

We have not tried it yet with the new API but we have seen 1-2 other very similar problems in other APIs in the last few months with fabric pages, relating to the conversion between ADF and SFXML not 100% intersecting. The copy page hierarchy API had an eerily similar problem (that was fixed after a while). The REST API for saving page content still has similar errors in some cases when trying to save exactly the same SFXML content that the page API itself returns. I was not surprised to see this report, because it smells like more conflicts between new and old storage formats.

Also, I would be happy to try replicating tomorrow if that’s of interest.

EDIT: Can I ask why this post was hidden? It seems to be contrary to the shift away from developers using DEVHELP tickets so that problem discussions would occur in the open.

@BobBergman thanks for those insights. Are there still confluence cloud sites using the old format?

Also I’m not sure why my post was hidden, my other two posts in this forum have also been hidden by the system. No idea what’s going on there.

1 Like

Yeah, there are many sites still supporting the legacy page format. I don’t honestly know how this all works under the hood except that there are two data formats now, and they do not 100% intersect in features, and they get translated to and from one another in various contexts.

It’s also very possible that these issues are unrelated to what we had seen before.

Re: Posts hidden. I don’t know what happened the system account decided 4 posts were from new users even though they weren’t. One of my posts was hidden as well.

It wasn’t a manual decision to hide them. Looks like they have all been restored since then.

Update: @michael-k triggered the new user spam threshhold by posting the url to his heroku descriptor in multiple threads and multiple replies.

This new user tried to create multiple posts with links to the same domain. All posts from this user that include links should be reviewed. See the newuser_spam_host_threshold site setting.

2 Likes

Just to be clear the problem posted on this page is not because we’re copying a page from the old editor to the new editor correct? @michael-k seemed to indicate that he’s not using the older editor in his last reply.

@rwhitbeck that’s correct. I create a page using the editor, copy the page using the API, then try to edit the copied page using the same editor. I’m not sure how to determine the version of the editor. Attached is a screenshot of the editor incase that helps.

I just started fiddling with this to see if I could reproduce it. After a very brief attempt to replicate it using an admin user, I have not yet seen the same problem. On my second test, however, I found that both a basic image macro and the viewpdf macro from the original page failed to copy effectively:

Input page:

Output page:

And here are the before and after storage formats of each page:

Input:

<p>This is an image:</p>
<ac:image ac:align="center" ac:layout="center" ac:original-height="667" ac:original-width="500">
  <ri:attachment ri:filename="keep-crom.jpg" ri:version-at-save="1" />
</ac:image>
<p>This is a pdf:</p>
<p class="media-group">
  <ac:structured-macro ac:name="view-file" ac:schema-version="1" ac:macro-id="11ad8069-ea60-4998-9556-47637a794905">
    <ac:parameter ac:name="name">
      <ri:attachment ri:filename="thecozyapron.com-Pan Seared Salmon for When the Simplest Things Just Make You Happy.pdf" ri:version-at-save="1" />
    </ac:parameter>
  </ac:structured-macro>
</p>
<p>This is an inlined pdf:</p>
<ac:structured-macro ac:name="viewpdf" ac:schema-version="1" data-layout="default" ac:macro-id="22225768-66c1-405f-b7b0-6b64e1c94913">
  <ac:parameter ac:name="name">
    <ri:attachment ri:filename="thecozyapron.com-Pan Seared Salmon for When the Simplest Things Just Make You Happy.pdf" ri:version-at-save="1" />
  </ac:parameter>
</ac:structured-macro>

Output:

<p>This is an image:</p>
<ac:image ac:align="center" ac:layout="center" ac:original-height="667" ac:original-width="500">
  <ri:attachment ri:filename="keep-crom.jpg" ri:version-at-save="1">
    <ri:page ri:space-key="CG" ri:content-title="[ADF] Attachments" ri:version-at-save="1" />
  </ri:attachment>
</ac:image>
<p>This is a pdf:</p>
<p class="media-group">
  <ac:structured-macro ac:name="view-file" ac:schema-version="1" ac:macro-id="16b61a64-23cf-40b6-9e6f-7843c0447982">
    <ac:parameter ac:name="name">
      <ri:attachment ri:filename="thecozyapron.com-Pan Seared Salmon for When the Simplest Things Just Make You Happy.pdf" ri:version-at-save="1">
        <ri:page ri:space-key="CG" ri:content-title="[ADF] Attachments" ri:version-at-save="1" />
      </ri:attachment>
    </ac:parameter>
  </ac:structured-macro>
</p>
<p>This is an inlined pdf:</p>
<ac:structured-macro ac:name="viewpdf" ac:schema-version="1" data-layout="default" ac:macro-id="22225768-66c1-405f-b7b0-6b64e1c94913">
  <ac:parameter ac:name="name">
    <ri:attachment ri:filename="thecozyapron.com-Pan Seared Salmon for When the Simplest Things Just Make You Happy.pdf" />
  </ac:parameter>
</ac:structured-macro>

@rwhitbeck

This morning we have a case of this problem (the original post, with permissions being broken on the copied page) being reported by a customer using our Copy Page Tree app, which uses the Copy Page Hierarchy REST API under the covers.

This is suddenly a much more urgent issue for us as it’s affecting app customers. How can we escalate quickly? We will be digging in and trying to get reproducer details. I will open a critical incident post if necessary.

1 Like

I’ve reached out to @BobBergman directly to understand more about their customers issues in a more private setting.

I’ll circle back here with any updates.

@rwhitbeck any updates on fixing this issue? I’m holding off launching a new marketplace app as it will undoubtedly lead to bug reports and bad reviews.

@BobBergman have you figured out any workarounds for the time being that I might be able use?

@michael-k We haven’t gotten to the bottom of it yet, but we have connected our customer with Atlassian for further investigation. I don’t think they’ve determined anything yet. AFAIK neither we nor Atlassian have been able to reproduce this problem. If this is a development instance of Confluence you are using that you could add me to as a user, I’d be interested in trying to reproduce it there. That’s a big ask though and I totally understand if you don’t want to do that. If not, perhaps you could invite Ralph to your instance and let him take a stab at reproducing it there. Either way, it might help validate the problem and gather better diagnostics?

@rwhitbeck I know I sort of hijacked the original post in some of my comments above, but I am wondering if anyone has taken a look at the other problems with the single page copy API’s handling of attachments that I pointed out above?