Changes to the Page Permission API in Confluence 2.4

Confluence 2.4 contains changes to the Confluence API that will affect any plugins that modify Page Permissions (aka ContentPermissions). Some methods have been deprecated, some new methods have been created, and one method now behaves differently from before.

Confluence 2.4 does not support having multiple view and edit permissions on a page. The Content Permission API allows such a state, but it should be avoided. For example, if a Page has multiple permissions set on it, these permissions will not be displayed properly via the user interface, and the pages may not be returned appropriately in a search.

Summary of Changes

Deprecated methods

ContentPermissionManager.getInheritedContentPermissions(ContentEntityObject contentEntityObject)

ContentEntityObject.getContentPermission(String permissionType)

Changed methods

ContentPermissionManager.addContentPermission(ContentPermission permission, ContentEntityObject content)

Added methods

ContentPermissionManager.setContentPermissions(List contentPermissions, ContentEntityObject content, String type)
ContentPermissionManager.getInheritedContentPermissionSets(ContentEntityObject contentEntityObject)

ContentEntityObject.getContentPermissionSet(String type)

ContentEntityObject.hasPermissions(String type)
ContentEntityObject.removeContentPermissionSet(ContentPermissionSet set)

Removed methods

ContentPermissionManager.saveContentPermission(ContentPermission permission)
ContentPermissionManager.getContentUserPermission(ContentEntityObject contentEntityObject)
ContentPermissionManager.onContentContextChanged(ContentEntityObject contentEntityObject)

ContentEntityObject.setPermissions(List permissions)
ContentEntityObject.clearPermissions(ContentPermissionManager permissionManager)

The change most likely to cause problems is:

ContentPermissionManager.addContentPermission(ContentPermission permission, ContentEntityObject content)

This method now adds a ContentPermission to the ContentEntityObject as one would expect. Previously if a ContentPermission already existed on the ContentEntityObject, then any existing ContentPermission would be removed. That is, the method really behaved as one would expect "setContentPermission" to behave. As a result, any code that used addContentPermission in Confluence 2.3 or earlier, should now use setContentPermissions with a single entry list.

Example conversion of old addContentPermission usage
ContentPermissionManager.addContentPermission(p, c)
ContentPermissionManager.setContentPermissions(java.util.Collections.singletonList(p), c, p.getType())

Most methods that used to return a ContentPermission have been replaced with methods that return a ContentPermissionSet. In some places we have used deprecation to point to the new method and reimplemented the old method to extract the first ContentPermission from the ContentPermissionSet.

As usual, the methods on the ContentPermissionManager should be used rather than those on the ContentEntityObject. The only ContentEntityObject method that should be used is getContentPermissionSet. Even that method should be used only to display the existing Permissions. All writes to the ContentPermissionSets should be performed via the ContentPermissionManager.

The onContentContextChanged method of the ContentPermissionManager was previously used to notify a ContentPermissionManager that cached permissions on a ContentEntityObject may be invalid. This is now accomplished by publishing a ContentPermissionEvent. That event is published automatically when changing ContentPermissions via the ContentPermissionManager.

No changes have been made yet to the the XML RPC API. It does not currently allow modification of ContentPermissions.

Was this helpful?

Thanks for your feedback!

Why was this unhelpful?

Have a question about this article?

See questions about this article

Powered by Confluence and Scroll Viewport