Permission handling

Version 3.1 by Josué Tille on 2026/04/20 16:13

Reference

When migrating Confluence permissions to XWiki rights, here is what happens:

Page permissions

Permissions set on a Confluence page are converted to XWiki rights set on the corresponding document following this table:

Confluence permissionXWiki right
VIEW

VIEW on the corresponding page and its children (in a XWikiGlobalRights object on the WebPreferences document corresponding to the page)

EDITEDIT on the page (in a XWikiRights object on the corresponding WebHome document)
SHARE(ignored, we don't have any corresponding right in XWiki)

Space permissions

Permissions set on a Confluence space are converted to inherited XWiki rights set on the corresponding WebPreferences page of the space  in XWikiGlobalRights objects, following this table:

Confluence permissionXWiki right
VIEWSPACEVIEW

EDITSPACE
EDITBLOG
Note: in the Confluence UI, this is what is called "Add" page right

EDIT
REMOVEBLOG
REMOVEPAGE
DELETE
COMMENTCOMMENT

ADMINISTRATECONFLUENCE
SYSTEMADMINISTRATOR
SETPAGEPERMISSIONS
SETSPACEPERMISSIONS

ADMIN
(other)(ignored)

 Note that Confluence propose many fine-grained permission for which XWiki don't have corresponding rights (including, but not limited to: EXPORTSPACE, EXPORTPAGE, REMOVEMAIL, REMOVEOWNCONTENT, CREATEATTACHMENT, REMOVEATTACHMENT, REMOVECOMMENT, PROFILEATTACHMENTS, ARCHIVEPAGE). If such a feature is needed, some custom solution needs to be found.

View right propagation, edit right handling and differences in permission management

In Confluence,

  • rights can only be further restricted. We can't open up rights in a sub page. When permissions are set to pages, they can only limit the number of users to which they grant rights. It's not possible to allow more people than those who can access parent pages. This means that if on Page A, VIEW restriction is set for Group A, and on Sub Page B, VIEW right is set for Group B, only people that are both in Group A and in Group B are allowed to see Sub Page B. It is not enough to be in Group B. We'll have to do with the fact that the migrated Sub Page B will be allowed to the whole Group B, and we'll document this discrepancy between Confluence and XWiki, unless someone is willing to setup custom right management in XWiki, which is not advisable in most cases and can surprise users who already know XWiki, and support teams
  • edit rights can be granted to users on pages , but they won't be able to edit those pages if they don't have edit permissions on the space.

In XWiki, rights will be opened up. All users of group be will be able so see Sub Page B, and a user will be able to edit a page if edit right is set for this user, even if the user didn't have edit rights on the space in Confluence.

Page restriction right in confluence and migration to XWiki

In confluence there are page restriction right at space level. This right is converted to admin right (of the space) in XWiki. This means that all user having page restriction right but not admin right on confluence would result in an escalation of rights for theses user, in all the space. It means that for all users having the page restriction right in confluence, in XWiki theses same users can see any sub-pages even if there are specific rights for theses pages.

Get Connected