Wiki source code of Permission handling
Last modified by Raphaël Jakse on 2026/05/27 16:56
Show last authors
| author | version | line-number | content |
|---|---|---|---|
| 1 | When migrating Confluence permissions to XWiki rights, here is what happens: | ||
| 2 | |||
| 3 | == Page permissions == | ||
| 4 | |||
| 5 | Permissions set on a Confluence page are converted to XWiki rights set on the corresponding document following this table: | ||
| 6 | |||
| 7 | (% summary="How Confluence page permissions are migrated to XWiki rights on documents" %) | ||
| 8 | |=Confluence permission|=XWiki right | ||
| 9 | |VIEW|((( | ||
| 10 | VIEW on the corresponding page and its children (in a XWikiGlobalRights object on the WebPreferences document corresponding to the page) | ||
| 11 | ))) | ||
| 12 | |EDIT|EDIT on the page (in a XWikiRights object on the corresponding WebHome document) | ||
| 13 | |SHARE|(ignored, we don't have any corresponding right in XWiki) | ||
| 14 | |||
| 15 | == Space permissions == | ||
| 16 | |||
| 17 | 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: | ||
| 18 | |||
| 19 | (% summary="How Confluence page permissions are migrated to XWiki rights on documents" %) | ||
| 20 | |=Confluence permission|=XWiki right | ||
| 21 | |VIEWSPACE|VIEW | ||
| 22 | |((( | ||
| 23 | EDITSPACE | ||
| 24 | EDITBLOG | ||
| 25 | **Note: in the Confluence UI, this is what is called "Add" page right** | ||
| 26 | )))|EDIT | ||
| 27 | |REMOVEBLOG | ||
| 28 | REMOVEPAGE|DELETE | ||
| 29 | |COMMENT|COMMENT | ||
| 30 | |((( | ||
| 31 | ADMINISTRATECONFLUENCE | ||
| 32 | SYSTEMADMINISTRATOR | ||
| 33 | SETPAGEPERMISSIONS | ||
| 34 | SETSPACEPERMISSIONS | ||
| 35 | )))|ADMIN | ||
| 36 | |(other)|(ignored) | ||
| 37 | |||
| 38 | 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. | ||
| 39 | |||
| 40 | {{warning}} | ||
| 41 | In XWiki, some rights imply others. For instance, a user having DELETE right on a page automatically and implicitly has VIEW rights. The Confluence permission to XWiki right conversion is generally naive 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. | ||
| 42 | |||
| 43 | In the same spirit, 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. | ||
| 44 | {{/warning}} | ||
| 45 | |||
| 46 | == View right propagation, edit right handling and differences in permission management == | ||
| 47 | |||
| 48 | In Confluence, | ||
| 49 | |||
| 50 | * 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 | ||
| 51 | * 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. | ||
| 52 | |||
| 53 | 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. | ||
| 54 | |||
| 55 | == Page restriction right in Confluence and migration to XWiki == | ||
| 56 | |||
| 57 | In Confluence there are [[page restriction rights>>https://confluence.atlassian.com/spaces/CONF85/pages/1283359733/Page+restrictions]] 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). |
