-
Bug
-
Resolution: Won't Fix
-
Medium
-
None
-
CCMA - 3.4.12, CCMA - 3.4.13
-
Severity 1 - Critical
-
6
Issue Summary
When an app macro in server stores some data in the pages as content property via ContentPropertyManager API the properties are stored in the contentproperties table. The data from that table is migrated to the cloud via Space import or CCMA, but the GET wiki/rest/api/content/{contentid}/property can't retrieve that data. This is because that API endpoint expects the data to be saved in the content table instead.
CCMA and the Space import engine should be able to convert that data so it can be accessed by the Cloud Rest API.
We can either have the ContentPropertyManager content properties to be available in Cloud after a Server → Cloud migration or we have the ContentPropertyService content properties to drop/delete perm checks or provide overloaded methods to create/update/delete without having page EDIT perms.
Or is there is some other alternative API. Like, what is populating the CONTENTPROPERTIES table? Is that data available in Cloud? Why the ContentPropertyManager is using OS_PROPERTYENTRY and not CONTENTPROPERTIES?
This is reproducible on Data Center: (yes) / (no)
Steps to Reproduce
- Create some content properties on the server via ContentPropertyManager => com.atlassian.confluence.core.ContentPropertyManager.setTextProperty(ContentEntityObject contentObject,String votePropertyKey, String votePropertyValue);
- Migrate the space containing the content properties to the cloud via Space Import or via CCMA.
- Look for the properties on the Database: select * from contentproperties where contentid = 123456
- Run API's to get the content properties: wiki/rest/api/content/123456/property/ or wiki/rest/api/content/123456/?expand=<propertyname>
Expected Results
The content properties should be returned by the API.
Actual Results
The API does not return existing properties
Workaround
Developers can either use ContentPropertyService and store their content properties, or store their content in an AO_ table and migrate the data with the App Migration platform.
| Form Name | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
[MIG-1450] Content properties stored in pages via ContentPropertyManager are not migrated by CCMA
Hi All,
A quick update at the request of the Developer and Marketplace Support Team.
The changes introduced in the ContentPropertyService are intentional and required. We aligned the permissions for content properties with page permissions as changing content properties can have a material effect on pages, and it's far from apparent to users that a change to a page permission will not apply to other systems that interact with that page. With this consideration, we are not planning to make permissions pluggable. It's worth noting that JsonContentProperty and ContentPropertyService are both 9 years old and introduced in Confluence 5.6.0.
Thanks,
James Ponting
Engineering Manager - Confluence Data Center
I have found that the content properties in the REST API are migrated to Cloud along with the pages that own the content properties.
They are the properties managed by the ContentPropertyService. They are persisted in the CONTENT and BODYCONTENT tables.
One big difference between the ContentPropertyManager and this ContentPropertyService I'm looking at is that ContentPropertyService requires page EDIT perms for create/update/delete. The ContentPropertyManager had no such requirement.
The permission issue will need to be figured out because our use case is for anyone with VIEW perms for page to be able to use content properties. Our content properties persist shared data for a macro used for collaboration.
My first guess is that it is possible to change the perm check in the ContentPropertyManager: I see that the ContentPropertyServiceImpl constructor takes a Validator instance as an arg. I will see if I can write my own Validator impl that does not check for an EDIT perm and then see if I can deploy a custom ContentPropertyService component via Spring (using a <component> element in atlassian-plugin.xml).
Hi Team,
Is there any update?
We are blocked due to this issue.
Looking forward for an update.
Thanks
Atlassian,
On the topic of a workaround, how about having users migrate to a different page/content property framework? A newer one? One that IS migrated when a page is migrated from Server to Cloud?
I think that the REST API "content properties" are newer: https://developer.atlassian.com/server/confluence/content-properties-in-the-rest-api/
Are they migrated from Server to Cloud when a page is migrated? Where are they persisted in the DB?
Also, where is the JAVA API for those new content properties? That doc says, “Content properties are accessible both by Java and REST APIs.” but I don’t think it gives any detail about what/where for the Java APIs. With a quick glance at the Confluence source code I did not find the Java API that backs the REST API.
Thanks.
Hi Team,
Based on the latest update from engineering, I will be closing this bug report out as Won't Fix as the recommend way is to use ContentPropertyService or store the data elsewhere.
Regards,
James.