Extension:PageOwnership
PageOwnership is a permissions manager by which system administrators and entitled users can assign multiple layers of permissions to specific users or groups, either at page and namespace level, or for the entire wiki, through a user-friendly interface. Supports Transclusion, cache and Semantic MediaWiki.
Starting from version 1.1.0 PageOwnership supports in a rigorous way all the permissions and rights available in MediaWiki, through a user-friendly interface, and does not anymore rely on arbitrary permissions, without a strict correspondence in the MediaWiki's permissions/rights model!
Installation
[edit]- Download and move the extracted
PageOwnershipfolder to yourextensions/directory.
Developers and code contributors should install the extension from Git instead, using:cd extensions/
git clone https://gerrit.wikimedia.org/r/mediawiki/extensions/PageOwnership - Add the following code at the bottom of your LocalSettings.php file:
wfLoadExtension( 'PageOwnership' );
- Run the update script which will automatically create the necessary database tables that this extension needs.
Done â Navigate to Special:Version on your wiki to verify that the extension is successfully installed.
 Warning: | Do not use this extension to secure sensitive information! It has not been designed to do so and data could be accessed elsewhere. When used to prevent access to specific pages, only use it as a way to moderate contents before their actual publishing! |
Features
[edit]PageOwnership allows to assign multiple sets or layers of rights to specific users and groups, with regard of the entire wiki or based on specific pages, sub-pages and namespaces. This allows to comply with virtually any preventing-access need, ranging from just using PageOwnership as an interface for managing Mediawiki's permissions and rights in a traditional way, up to assigning specific pages and their sub-pages to specific users and groups, while preventing other groups of users from accessing or editing them.
PageOwnership, due to its flexibility, also allows to enforce an implicit moderation on your wiki. You don't directly moderate pages (or page versions) like in FlaggedRevs or Approved Revs, instead, you assign a page and its sub-pages to authorized user(s) or group(s) which can edit them. When the page is ready for publishing, either you grant to everybody access to it, or you provide the editors of the page with additional rights related to that page and sub-pages (so they can in turn provide other users or groups with access to it).
Managing permissions
[edit]PageOwnership's Permissions Manager can be accessed both from any article of the wiki, through the navigation menu shown above, or from the list of special pages.
The Permissions Manager consists of two different special pages (or "steps" within a unique special page by a technical point of view), the first with all the sets of permissions related to the entire wiki (if the Permissions Manager has been accessed from the list of special pages) or to the related page (of any namespace) – and the second listing specific rights and permissions assigned to specific users or groups.
Here is the navigable list of permissions assigned to a "Test page", and the button "Add permissions" by which you can add a new set of permissions.
The first entry assigns the permissions types "Reading" and "Editing" to the user "Account test 1", plus specific additional rights provided by PageOwnership which extend the given rights to sub-pages of the related page as well, and it removes a right included in the standard set of "Editing" permissions ("Move pages").
The second entry matches all the anonymous and registered users, and assign to them no rights. By this way all the anonymous and registered users are prevented either to access and edit "Test page" and any of its sub-pages.
Also note that the rights associated to "Reading" and "Editing" permissions types are not arbitrary but reflect the table provided at Manual:User rights. See the table below for a complete overview.
Setting permissions
[edit]From the navigable list of permissions within the Manage permissions special page (also known as "pager"), you can access the form to set permissions associated to any user, group, page, and namespace through the "add permissions" button or "edit" button besides each existing set of permissions. Here it is:
Through the first input you can enter both users and groups, and through the second input (a custom OOUI "multi toggle button widget") you can assign set of rights to that user and group subdivided by type. As mentioned above, such types are not arbitrary but reflect the table provided in the Manual:User rights page, which are the following:
| permissions type | associated rights |
|---|---|
| Reading | read
|
| Editing | applychangetags, autocreateaccount, createaccount, createpage, createtalk, delete-redirect, edit, editsemiprotected, editprotected, minoredit, move, move-categorypages, move-rootuserpages, move-subpages, movefile, reupload, reupload-own, reupload-shared, sendemail, upload, upload_by_url
|
| Management | bigdelete, block, blockemail, browsearchive, changetags, delete, deletedhistory, deletedtext, deletelogentry, deleterevision, editcontentmodel, editinterface, editmyoptions, editmyprivateinfo, editmyusercss, editmyuserjs, editmyuserjsredirect, editmyuserjson, editmywatchlist, editsitecss, editsitejs, editsitejson, editusercss, edituserjs, edituserjson, hideuser, markbotedits, mergehistory, pagelang, patrol, patrolmarks, protect, rollback, suppressionlog, suppressrevision, unblockself, undelete, userrights, userrights-interwiki, viewmyprivateinfo, viewmywatchlist, viewsuppressed
|
| Administration | autopatrol, deletechangetags, import, importupload, managechangetags, siteadmin, unwatchedpages
|
| Technical | apihighlimits, autoconfirmed, bot, ipblock-exempt, nominornewtalk, noratelimit, override-export-depth, purge, suppressredirect, writeapi
|
Also note that because this subdivision does not reflect the rights assigned by default to each user (for instance the editprotected right is reserved to sysop by default, and obviously the createaccount right does not apply to the user group), in future version of the extension an additional subdivision per group, as in the table Manual:User_rights#List_of_groups, might be added, while currently you can add/remove rights through the additional inputs "Add/remove specific permissions".
The "Additional rights" input contains all available rights not included in the subdivision above, namely the rights provided by extensions.
Finally, the inputs "Add specific permissions" and "Remove specific permissions", using a OOUI's MenuTagMultiselectWidget, allows to add/remove specific permissions to/from the described types of permissions, and get automatically populated depending on the selected types, so you can have a precise idea of the rights actually assigned.
Currently, as for the version 1.1.0 PageOwnership, by contrast to previous versions, does not feature a dedicated input (before it was a checkbox) to manage its own set of permissions (see section Rights and privileges), but instead offers an "universal" way to manage all available permissions. This does not exclude that a coming version of PageOwnership could again include a dedicated input to manage subpages' permissions (a core feature of PageOwnership), through a simplified interface available besides the complete interface, however that will be internally handled through the more "universal" right and permissions model now adopted.
When accessed from the list of Special Pages, the Set permissions form also features two inputs to restrict the current set of permissions to specific page(s) and to specific namespace(s).
Special groups/rights
[edit]From version 1.2.0 permissions to manage subpages have been improved and simplified by removing the rights "read/create/edit/move subpages (Page Ownership)" and replacing them with an unique right Includes subpages (Page Ownership), that allows to extend the set of permissions assigned to an article, to its subpages, including those yet to be created.
Additionally, a new dynamic group is now available, Article creator (Page Ownership), which is automatically assigned to an user as long as they are the article creator, i.e., the user who created the first revision of an article. This group has been inspired by the extension Extension:LockAuthor and accomplishes a similar purpose.
Both the special group "Article creator (Page Ownership)" and the special permission "Includes subpages (Page Ownership)" add an increased flexibility when combined with all other permissions and the way they can be managed. See below Extension:PageOwnership#Article_creator for a use-case.
Filtering permissions
[edit]The centralized list of permissions (when accessed from the list of Special Pages instead than from the action menu on top of content pages) can be filtered and includes fields with the related page or namespace and the user who created the permission.
"My pages" sidebar section
[edit]PageOwnership creates a list of pages to which logged-in registered users have been assigned (as users, not as members of a group) in the standard navigation panel, so that they can quickly navigate to such pages.
 | To disable this feature set $wgPageOwnershipDisableSidebarPages = true; in Manual:LocalSettings.php |
Magic word/parser function
[edit]PageOwnership includes a Magic word/parser function (called either using {{pageownership userpages}} or {{#pageownership userpages:}}) (case insensitive) to display the list of pages assigned to the logged-in registered user. This can be used within articles or templates for various purposes.
Use-cases
[edit]Confidential pages
[edit]The following set of rights represent the current PageOwnership's permissions for an entire private wiki and are shown through Special:SpecialPages -> PageOwnership -> ManagePermissions (i.e. not from the action menu from a wiki article).
The first row is the most significant: it matches all users (including anonymous users, also if this is not relevant for a private wiki) and sets for them no rights (the related cell is empty) for "Confidential page a" and "Confidential page b".
The second row grants User a and User b, reading and editing-related rights (including subpages) for the page "Confidential page a".
The third row grants User c and User d, reading and editing-related rights for the page "Confidential page b".
In summary the wiki has 2 confidential pages, and those can be edited/accessed only from specific users.
Guest user
[edit]If we want to set a "guest user" (an user who is only allowed to access specific pages) we add the following permissions.
The first row matches "User e" and assigns no rights to he/she for all pages and namespaces (the related empty cells have a meaningful semantic meaning in this case)
The second row matches the same user and assigns he/she with editing-related and reading right for a "Page x".
Note in short the composite character of PageOwnership's permissions: you first match an user or group and assign to them basic permissions or no permissions, and then you grant more permissive permissions on specific pages or namespaces.
Article creator
[edit]The following settings illustrate the use of the special group "Article creator (Page Ownership)" and the special right "Includes subpages (Page Ownership)" . The first row, applied to a specific page, removes all rights for all users, and the second row assigns reading and editing permissions to the creator of such page and all its subpages.
The group "Article creator (Page Ownership)" also matches creators of newly created pages, therefore when used in conjunction with "Includes subpages (Page Ownership)" can be used to pre-assign permissions to pages yet to be created.
Namespace permissions
[edit]The following permissions have been assigned using the Special page "Special:PageOwnershipPermissions" (accessible from "Special:SpecialPages") and are not related to any specific page.
The first row removes all permissions related to all pages and namespaces of the wiki for all users, and the 2nd row assigns reading permissions to all namespaces of the wiki except Special. This way, the wiki is read-only for all users, special pages aren't accessible (except Log in) and specific namespaces or set of pages/subpages can be set as editable through additional sets of permissions.
Rights and privileges
[edit]The extension creates the following user rights. Note that because MediaWiki does not offer by default a per-page management of rights, it makes sense to use pageownership-include-subpages only through the PageOwnership's Manage permissions special page.
| right | description |
|---|---|
pageownership-canmanagepermissions |
Can manage permissions of the entire wiki |
pageownership-caneditpermissions |
Can edit permissions |
pageownership-include-subpages |
Include subpages in the current set of permissions |
Groups
[edit]| group | pageownership-canmanagepermissions | pageownership-caneditpermissions |
|---|---|---|
sysop |
v | v |
bureaucrat |
v | v |
pageownership-admin |
v | v |
| As of version 1.2.0 PageOwnership also includes the group pageownership-article-author which is automatically assigned to the creator of a given article |
Global parameters
[edit]| variable | description | default |
|---|---|---|
$wgPageOwnershipDisableSidebarPages |
disables list of protected pages related to logged-in user on the sidebar | false
|
$wgPageOwnershipAdmins |
array of usernames or groups with all permissions | sysop |
$wgPageOwnershipWhitelistSpecials |
array of white-listed special pages | [ "Search", "Userlogin", "CreateAccount", "Preferences", "ChangeEmail", "Confirmemail" ]
|
$wgPageOwnershipDisableVersionCheck |
disable check of new version of the extension | false
|
API
[edit]Since version 1.2.1 PageOwnership includes the following APIs. They allow to set/get sets of permissions both through the client-side MW api, and from PHP, using the methods \PageOwnership::setPermissionsApiCall and \PageOwnership::getPermissionsApiCall.
| action | description | must be posted | allowed users |
|---|---|---|---|
pageownership-set-permissions |
set permissions | yes | sysop, bureaucrat, pageownership-admin |
pageownership-get-permissions |
get permissions | yes | sysop, bureaucrat, pageownership-admin |
Here are the expected parameters for each of them
| parameter | description | required |
|---|---|---|
usernames |
comma separated values of target usernames/groups for the set of permissions | true |
permissions-by-type |
any of: reading, editing, management, administration, technical | false |
additional-rights |
additional rights set by extensions as listed using RequestContext::getMain()->getConfig()->get( 'AvailableRights' ) |
false |
add-permissions |
assign specific permissions as specified in the table "Permissions by type" in the section #Setting_permissions | false |
remove-permissions |
remove specific permissions as specified in the table "Permissions by type" in the section #Setting_permissions | false |
paegids |
comma separated list of page ids, to which constrain/limit the current set of permissions | false |
namespaces |
comma separated list of namespace ids, to which constrain/limit the current set of permissions | false |
id |
id of an existing set of permissions to update (retrieved using the api pageownership-get-permissions) |
false |
The api pageownership-get-permissions is mainly used to avoid to inadvertently set the same set of permissions multiple times, so a third party script or extension is expected to first verify if the desired set of permissions for a given set of users and/or groups exists, and then to add or replace it after evaluating the api's response.
| parameter | description | required |
|---|---|---|
usernames |
comma-separated values of target usernames/groups | true |
paegids |
comma-separated list of page ids | false |
namespaces |
comma-separated list of namespace ids | false |
created-by |
actor who performed the action | false |
id |
id of an existing set of permissions | false |
As mentioned both the APIs can be called from PHP as well using the methods \PageOwnership::setPermissionsApiCall and \PageOwnership::getPermissionsApiCall. See the class PageOwnership in the "includes" folder of the extension for their interface.
Known issues
[edit]- there isn't yet a maintenance script for migration, however the current version uses a new table name, so the previous table is kept intact
Support & bugs
[edit]Please post error messages in the Talk page of the extension. Updates will be posted on this element.io chat and occasionally in the MediaWiki's Wikitech mailing list.
For professional support please write at the email address posted here
Roadmap
[edit]- implement additional right "move subpages within root page"
- write use-case to emulate Extension:GroupWhitelist
- additional form section where to toggle all rights per-group
See also
[edit]- Stable extensions
- Hook extensions
- Special page extensions
- GPL licensed extensions
- Extensions in Wikimedia version control
- ArticleDeleteComplete extensions
- BeforeInitialize extensions
- BeforePageDisplay extensions
- BeforeParserFetchTemplateRevisionRecord extensions
- LoadExtensionSchemaUpdates extensions
- MagicWordwgVariableIDs extensions
- PageRenderingHash extensions
- PageSaveComplete extensions
- ParserFetchTemplate extensions
- ParserFirstCallInit extensions
- ParserGetVariableValueSwitch extensions
- ParserOptionsRegister extensions
- RejectParserCacheValue extensions
- SMW::Store::AfterQueryResultLookupComplete extensions
- SiteNoticeBefore extensions
- SkinBuildSidebar extensions
- SkinTemplateNavigation::Universal extensions
- TitleQuickPermissions extensions
- GetUserPermissionsErrors extensions
- All extensions
- Page specific user rights extensions
- Semantic MediaWiki extensions