Permission handling
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 permission | XWiki right |
|---|---|
| VIEW | VIEW on the corresponding page and its children (in a XWikiGlobalRights object on the WebPreferences document corresponding to the page) |
| EDIT | EDIT 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 permission | XWiki right |
|---|---|
| VIEWSPACE | VIEW |
EDITSPACE | EDIT |
| REMOVEBLOG REMOVEPAGE | DELETE |
| COMMENT | COMMENT |
ADMINISTRATECONFLUENCE | ADMIN |
| (other) | (ignored) |
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.
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).
