using contentPropertyService.create() for a user without edit permission?

Question

Confluence 6.0.3

With a POM2 plugin I need to create json properties on a page via the ContentPropertyService. This is triggered within a LabelEvent listener.

This fails when the user has no edit permission on the page. Any idea how to 'force' saving properties even when the user has no edit permission?

This is the message I get:

validationResult.validateCreate=SimpleValidationResult{authorized=false, errors=[]}

Ture Hoefner {Appfire} · Answer

I don't see this topic over in the dev community.  I'll probably start something over there.

I'm running into the same trouble:  the ContentPropertyService API requires page EDIT perms to create/update/delete custom content properties for a page.  This is inconsistent with all of the other APIs I have seen/used in Confluence.  They don't have perm checks so close to the method calls that do the actual CRUD.  Any perm checks are usually app code that is upstream of the API that is doing the CRUD.

This is an unfortunate design choice.  It makes custom content properties usable only for the page editor use-case.  These custom content properties cannot be used when viewing a page.  Only plugins that are used inside of the page editor can use them.

Collaboration plugins that are used in page view mode cannot use the ContentPropertyService API.

This is the only content property API that I know of that migrates its properties from Server to Cloud along with the page when it is migrated.  (A related problem is the collection of inconsistent content property impls out there)

3rd party apps that use page-scoped custom properties are struggling now with what to do because the Server/DC --> Cloud migration is such an important part of the ecosystem right now.

The ContentPropertyMANAGER custom content properties are correctly implemented w.r.t. perms (they do not do perm checks right in the create/update/delete impl) but they are in the OS_PROPERTYENTRY table and that is NOT migrated from Server to Cloud and those properties are not available via a Confluence Cloud REST API like the ContentPropertySERVICE properties are.  The ContentPropertySERVICE properties are in the CONTENT and BODYCONTENT tables and are available via REST API on both server and Cloud.

I'm going to take a guess:  the perm checks were implemented in the ContentPropertySERVICE API because it is what backs the REST API.  The REST API needs some perm checks and somebody made a few mistakes:  1) they put the perm checks in the create/update/delete methods in the backing Java API instead of encapsulating them outside/upstream of the Java API, 2) they did the wrong perm check: they should be checking page VIEW, not page EDIT.

A long and painful story.  Sorry, but I put it here because there are no other hits out there when searching for this problem.

Maarten Cautreels · Answer

Hi Rina,

The Atlassian User Community and Developer Community recently got split up.

It'll probably be better for you to ask your question at https://community.developer.atlassian.com/, you'll have a better chance of getting an answer there!

Best,

Maarten