Problem with content properties post-migration with multi-version content

Hi guys,

I noticed that our migrated content isn’t indexed on Confluence Cloud after migration and realised the there is a property “ac:custom-content:search-body” that we use to set keywords for indexed content. Of course I would like to have the migrated content indexed equally well as the cloud-created content is indexed.

Now, when creating new content in Cloud from scratch, this works fine. The property gets created on version 1 of the content and keywords get indexed properly. Also if we add new content versions, the indexing works fine with them as well, I guess because the property gets cloned always to a newer version starting from version 1.

However, here is the problem: If the migration contains content with more than one version, then this breaks down. Let’s say we have 3 versions of same content. None of them contains that property after the migration from Server and when I’m trying to update the keyword for that 3rd version, I get an error:

com.atlassian.confluence.api.service.exceptions.NotFoundException: Cannot update content property. Property : JsonContentProperty{id=‘null’, key=‘ac:custom-content:search-body’, content=CollapsedReference{idProperties={id=ContentId{id=499089537}, status=current, version=CollapsedReference{idProperties={number=0}, referentClass=class com.atlassian.confluence.api.model.content.Version}}, referentClass=class com.atlassian.confluence.api.model.content.Content}, version=Version{by=null, when=null, message=‘null’, number=3, syncRev=‘null’, syncRevSource=‘null’, ncsStepVersion=‘null’, ncsStepVersionSource=‘null’, confRev=‘null’, content=EmptyReference{referentClass=class com.atlassian.confluence.api.model.content.Content}}} , isSuccessful: false, isAuthorized: true, isValid: false, hasErrors: true, Errors: “Could not find Property to update.”

If I have some other content just with version 1, then this approach works well as the property does get created with the property POST-updating. But with more than 1 version already existing from the migration, then this breaks.

I guess root issue here is this (https://developer.atlassian.com/cloud/confluence/rest/api-group-content-properties/#api-wiki-rest-api-content-id-property-key-put): “Updates an existing content property. This method will also create a new property for a piece of content, if the property key does not exist and the property version is 1.

So basically would need to be able to create a new property for the latest migrated version 1. I have tried to use both of these APIs:

https://developer.atlassian.com/cloud/confluence/rest/api-group-content-properties/#api-wiki-rest-api-content-id-property-post

and

https://developer.atlassian.com/cloud/confluence/rest/api-group-content-properties/#api-wiki-rest-api-content-id-property-key-post

But I guess they both create the property only for version 1, as after calling either of these methods, I still get the same error above. If I could just pass the desired version with either of those above calls, that would resolve the issue.

So, any ideas how I could create a property for a migrated content with version >1?

EDIT: Ok, doesn’t seem to be working with content that has 1 version only. Then it is possible to add the ‘ac:custom-content:search-body’ property with keywords, but the content doesn’t become searchable even if I add those keywords there. I wonder if there is some specific call I need to make to get those keywords indexed after adding them all?

EDIT2: Hmm… or am I too quick to expect the keywords to appear in the search index immediately after post migration processing? Maybe it takes some time for them to be processed? I mean for the single-version content. Doesn’t help with multi-version content as I can add the property on those.

Regards,

  • Petri

Hi @PetriJuhaniRiipinen,

Thanks for your detailed post and sorry about these issues your having. I’m going to have to investigate this internally so it might take a day or two to get back to you on this.

Regards,
James.

I’m not sure if this is the same, but we had a “Could not find Property to update.” error and were able to solve it by adding "version": {"number": 1} property to the payload.

Hi Team,

Sorry but this dropped of my radar. I don’t have an accurate response but I do know that imported Spaces are indexed. But this is about custom content, so I’ll reach out internally and try and get an answer from the teams.

@PetriJuhaniRiipinen, does @MareinKnings solution work for you?

Adding "version": {"number": 1} seems like what the documentation is stating. looking at the version data, setting contentTypeModified to true might help also with triggering the index.

What would help us is a specific example so we can try and reproduce this issue.

James.

Hi @PetriJuhaniRiipinen,

If this is still an issue, can I get you you open a DEVHELP ticket so we can investigate further. If possible, can you provide

  • the tenant id
  • the date of migration
  • the custom content id
  • an example of the search query you used
  • an example of the expected and actual search result

Thanks,
James.

Hi @jrichards ,

Finally got back to this, lots of other things to do.

I think I’ll create a new fresh developer site, do one migration to it and create a DEVHELP-ticket so you guys can investigate it, probably doesn’t get resolved otherwise.

And no, the other solution didn’t work with searching.

  • Petri

@jrichards ,

I created this issue for a new problem that blocks my progress: Jira Service Management

Looks like the migrated space becomes restricted in Cloud and the post-migration webhook code is unable to access the pages or attachments. This didn’t happen in my old cloud developer site, but started happening today when I created a new developer cloud site to test the migration there.

I can’t proceed with the keyword-indexing issue before this issue gets resolved.

  • Petri

Hi @PetriJuhaniRiipinen,

I can see DEVHELP-7320, thanks for the information. I suspect you’re being affected by [MIG-837] Apps can't access restricted content in Confluence Cloud - Create and track feature requests for Atlassian products. but you mentioned that there are no space restrictions, so we’re going to have to look a bit more.

I’ll provide updates to DEVHELP-7320 and when we have a solution, I’ll post here so the community is updated as well.

Regards,
James.

@jrichards Content restrictions could be per page, does not have to be space restrictions (only).
That is a whole wider (and more complex) problem, if you think.
(This is just to add to [MIG-837] Apps can't access restricted content in Confluence Cloud - Create and track feature requests for Atlassian products., which is currently an absolute blocker for us)

Alex

Hi @jrichards

Yep, that MIG-837 looks very familiar behaviour to me, very likely same issue. Total showstopper for our migration processing for now.

  • Petri

Hi Team,

As an update this closed issue [CONFCLOUD-70693] ac:custom-content:search-body content property is not being indexed by the search - Create and track feature requests for Atlassian products. looks like it is happening again. We have an internal investigation ongoing about this.

I’ll update when I have more information.

Regards,
James.

Hi team,

An update on the investigations leads up to believe that [CONFCLOUD-73210] ac:custom-content:search-body content property is not indexed - Create and track feature requests for Atlassian products. is not a regression, but works as expected.

However, in the context of a migration it’s more likely that content is returning permission errors because of [MIG-905] App user cannot access Space after migrating with CCMA - Create and track feature requests for Atlassian products.. As a result of the MIG-905 issue, apps don’t have access to the content in a migrated Space. This is in addition to MIG-837.

In general, to confirm that the issue is migration related try to reproduce the REST calls on content created in Confluence Cloud manually vs. content that is migrated.

Regards,
James.