3 separate customers have reported this to us today and yesterday, so it seems to be a new issue on Cloud (or a big coincidence), even though this issue has existed on Server for many years. I can also only reproduce it on one instance but not on another, which speaks for it being a new problem.
Steps to reproduce:
- Create a page A
- Create a custom content object B that is attached to page A
- Add a JSON content property to B
- Trash page A
What happens now is that B still appears in CQL searches, although with "status": "trashed". Whenever B appears in the CQL results, expansions of content properties donât work for any custom content objects in the results, even for non-trashed ones.
Page A is shown in the trash, but object B is not. When trashing object B on its own before trashing page A, still only page A appears in the trash, but the problem does not occur and object B does not appear in search results.
The workaround for our customers is to purge the trash, or at least to purge those specific pages that had custom content attached. However, this is not an acceptable solution because:
- Purging the trash is only possible for space admins
- One user trashing a page might break other pages for other users without noticing, those users will not know what is causing the problem and how to solve it.
Concrete example
Our app attaches custom content objects of type ac:k15t-scroll-document-versions-for-confluence:document to pages. These custom content objects need a content property K15tDocsMetadata to work properly.
In my space TT I have two pages, Page 1 and Page 2. These pages each have a custom content object of the same title attached to them.
Searching for these custom content objects and expanding the content property (/rest/api/search?cql=space=TT%20and%20type="ac:k15t-scroll-document-versions-for-confluence:document"&expand=content.metadata.properties.K15tDocsMetadata) yields this correct result:
{
"results": [
{
"content": {
"id": "445317227",
"type": "ac:k15t-scroll-document-versions-for-confluence:document",
"status": "current",
"title": "Page 2",
"metadata": {
"properties": {
"K15tDocsMetadata": {
"id": "445317232",
"key": "K15tDocsMetadata",
"value": {
}
}
}
}
}
},
{
"content": {
"id": "445087765",
"type": "ac:k15t-scroll-document-versions-for-confluence:document",
"status": "current",
"title": "Page 1",
"metadata": {
"properties": {
"K15tDocsMetadata": {
"id": "445087770",
"key": "K15tDocsMetadata",
"value": {
}
}
}
}
}
}
],
"start": 0,
"limit": 25,
"size": 2,
"totalSize": 2,
"cqlQuery": "space=TT and type=\"ac:k15t-scroll-document-versions-for-confluence:document\"",
}
Now, I trash Page 2 (through the Confluence UI). Doing the same request as above now yields this result:
{
"results": [
{
"content": {
"id": "445317227",
"type": "ac:k15t-scroll-document-versions-for-confluence:document",
"status": "trashed",
"title": "Page 2",
"metadata": {
"_expandable": {
"currentuser": "",
"comments": "",
"simple": "",
"frontend": "",
"labels": "",
"likes": ""
}
}
}
},
{
"content": {
"id": "445087765",
"type": "ac:k15t-scroll-document-versions-for-confluence:document",
"status": "current",
"title": "Page 1",
"metadata": {
"_expandable": {
"currentuser": "",
"comments": "",
"simple": "",
"frontend": "",
"labels": "",
"likes": ""
}
}
}
}
]
}
As you can see, the object attached to Page 2 still appears in the results as trashed. However, the metadata.properties expansion is missing for both objects and is not even listed in _expandable.
If I modify the query in any way that only Page 1 is returned, for example by searching only for its ID, the expansion works properly again. If Page 1 was the first result, I could also achieve this with a limit=1, but because Page 2 is the first result, I cannot achieve that in this case (because the start parameter is not supported anymore).
I tried to find a way to exclude trashed items from the results, but havenât succeeded yet. In the documentation, a contentStatuses field is mentioned for the cqlcontext parameter, but I couldnât manage to get it to have any effect on my results at all.