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:

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:

Note that Confluence propose many fine-grained permission for which XWiki doesn'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.

XWiki implied rights and impact on view restrictions migrations

In XWiki, some rights imply others (see the documentation in Authorization API). The conversion of Confluence permissions into XWiki rights is handling rules rather than effects, and doesn't take this in account, which can lead to right escalation upon migration in some specific instances. For instance, if a user has a REMOVEPAGE permission on a space but doesn't have VIEWSPACE right, the conversion will grant them VIEW right on the space, because REMOVEPAGE right will be converted to the DELETE right which implies VIEW.

The main impact of this behavior is on the view restriction on pages, upon migration from Confluence, which, in XWiki, will be impacted by the rights implied by the rights inherited from the Confluence space level, which becomes a page tree in XWiki. For example, EDITSPACE or REMOVEPAGE right for a space in Confluence will become EDIT and DELETE in XWiki, for the parent page corresponding to the Confluence space and its children; the Confluence VIEW restriction on a page will become an access rule restricting the view right on that XWiki page, but this rule will not impact the inheritance of the EDIT and DELETE rights, and EDIT and DELETE will imply VIEW, on the restricted page. Note that if a restriction for the edit right is also present in Confluence, the migration will also convert this into an EDIT permission rule, which will overwrite the inherited EDIT right and prevent the implication of VIEW by the inherited EDIT, but the situation is preserved for the DELETE right).

For the same reason but with different effects, a COMMENT permission will be converted to a COMMENT right regardless whether a user has VIEW right on the corresponding pages. COMMENT doesn't implicitly give VIEW right, so this conversion is technically correct, but it can lead to confusing display on right management tools.

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 rights at space level. This right is converted to admin right in XWiki, for the page tree corresponding to the Confluence space in XWiki. This means that all user having page restriction right but not admin right on Confluence will endup having admin right for the corresponding page tree in XWiki. The difference is that, in Confluence, a user with page restriction rights cannot see or change restrictions for a page that is restricted away from them (thus not having access to it at all, de facto), while in XWiki the admin right at the level of a page tree can see all the pages in that page tree, even if these pages have further view or edit access rules set on them; the admin right is not deniable in XWiki, and it is cumulative on inheritance (as opposed to other rights which are "interrupted" by inheritance).