User rights are specific access and ability permissions that can be assigned to customizable user groups. Groups can then be assigned to (or removed from) users through the Special:Userrights Special page. See Help:Assigning permissions.
Access to this interface is itself governed by the 'userrights' right, so only users in the 'bureaucrat' group can do it (in a default set-up). See Manual:Setting user groups in MediaWiki for information about managing and the assignment of user groups.
Changing group permissions[edit | edit source]
$wgGroupPermissions['group']['right'] = true /* or false */;
(Note: In a default installation $wgGroupPermissions will be set in
DefaultSettings.php, but it is not present in
LocalSettings.php. You will then need to add it in that file.)
If a member has multiple groups, they get all of the permissions from each of the groups they are in. All users, including anonymous users, are in the
'*' group; all registered users are in the
'user' group. In addition to the default groups, you can arbitrarily create new groups using the same array.
Examples[edit | edit source]
This example will disable viewing of all pages not listed in $wgWhitelistRead, then re-enable for registered users only:
$wgGroupPermissions['*']['read'] = false; # The following line is not actually necessary, since it's in the defaults. Setting # '*' to false doesn't disable rights for groups that have the right separately set # to true! $wgGroupPermissions['user']['read'] = true;
This example will disable editing of all pages, then re-enable for users with confirmed e-mail addresses only:
# Disable for everyone. $wgGroupPermissions['*']['edit'] = false; # Disable for users, too: by default 'user' is allowed to edit, even if '*' is not. $wgGroupPermissions['user']['edit'] = false; # Make it so users with confirmed e-mail addresses are in the group. $wgAutopromote['emailconfirmed'] = APCOND_EMAILCONFIRMED; # Hide group from user list. $wgImplicitGroups = 'emailconfirmed'; # Finally, set it to true for the desired group. $wgGroupPermissions['emailconfirmed']['edit'] = true;
Creating a new group and assigning permissions to it[edit | edit source]
You can create new user groups by defining permissions for the according group name in
$wgGroupPermissions['<group-name>'] where <group-name> is the actual name of the group.
Additionally to assigning permissions, you should create these three wiki pages with fitting content:
- MediaWiki:Group-<group-name> (content:
Name of the group)
- MediaWiki:Group-<group-name>-member (content:
Name of a member of the group)
- MediaWiki:Grouppage-<group-name> (content:
Name of the group page)
Examples[edit | edit source]
This example will create an arbitrary "ninja" group that can block users and delete pages, and whose edits are hidden by default in the recent changes log:
$wgGroupPermissions['ninja']['bot'] = true; $wgGroupPermissions['ninja']['block'] = true; $wgGroupPermissions['ninja']['delete'] = true;
- Note: the group name cannot contain spaces, so use
In this example, you would probably also want to create these pages:
- MediaWiki:Group-ninja (content:
- MediaWiki:Group-ninja-member (content:
- MediaWiki:Grouppage-ninja (content:
This will ensure that the group will be referred to as "Ninjas" throughout the interface, and a member will be referred to as a "ninja", and overviews will link the group name to Project:Ninjas.
This example disables write access (page editing and creation) by default, creates a group named "Write", and grants it write access. Users can be manually added to this group via Special:UserRights:
$wgGroupPermissions['*']['edit'] = false; $wgGroupPermissions['*']['createpage'] = false; $wgGroupPermissions['user']['edit'] = false; $wgGroupPermissions['user']['createpage'] = false; $wgGroupPermissions['Write']['edit'] = true; $wgGroupPermissions['Write']['createpage'] = true;
In this example, you would probably also want to create these pages:
- MediaWiki:Group-Write (content:
- MediaWiki:Group-Write-member (content:
- MediaWiki:Grouppage-Write (content:
Removing predefined groups[edit | edit source]
MediaWiki out of the box comes with a number of predefined groups. These groups can be removed by unsetting the according array keys, among them
$wgGroupPermissions['<group-name>']. For details see below.
Example[edit | edit source]
This example will eliminate the bureaucrat group entirely. It is necessary to ensure that all six of these variables are unset for any group that one wishes to remove from being listed at Special:UserGroupRights; however, merely unsetting $wgGroupPermissions will suffice to remove it from Special:UserRights. This code should be placed after any
require_once lines that add extensions such as Extension:Renameuser containing code that gives bureaucrats group permissions by default.
unset( $wgGroupPermissions['bureaucrat'] ); unset( $wgRevokePermissions['bureaucrat'] ); unset( $wgAddGroups['bureaucrat'] ); unset( $wgRemoveGroups['bureaucrat'] ); unset( $wgGroupsAddToSelf['bureaucrat'] ); unset( $wgGroupsRemoveFromSelf['bureaucrat'] );
List of permissions[edit | edit source]
The following user rights are available in the latest version of MediaWiki. If you are using an older version, look at "Special:Version" on your wiki and see if your version is covered in the "versions" column.
|read||allows viewing pages (when set to false, override for specific pages with $wgWhitelistRead).
|edit||allows editing unprotected pages.||1.5+|
|createpage||allows the creation of new pages (requires the edit right).||1.6+|
|createtalk||allows the creation of new talk pages (requires the edit right).||1.6+|
|move||allows renaming the titles of unprotected pages (requires the edit right).||1.5+|
|movefile||allows renaming pages in the "File" namespace (requires the move right and $wgAllowImageMoving to be true).||1.14+|
|move-subpages||move subpages along with page (requires the move right).||1.13+|
|move-rootuserpages||can move root pages in the "User" namespace (requires the move right).||1.14+|
|createaccount||allows the creation of new user accounts.||1.5+|
|upload||allows the creation of new images and files (requires the edit right).||1.5+|
|reupload||allows overwriting existing images and files (requires the upload right).||1.6+|
|reupload-own||allows overwriting existing images and files uploaded by oneself (requires the upload right).||1.11+|
|reupload-shared||allows replacing images and files from a shared repository (if one is set up) with local files (requires the upload right).||1.6+|
|upload_by_url||allows uploading by entering the URL of an external image (requires the upload right).||1.8+|
|editprotected||allows to edit protected pages (without cascading protection).||1.13+|
|editsemiprotected||allows to edit semiprotected pages (without cascading protection).||1.22+|
|applychangetags||allows to add tags while editing.||1.25+|
|delete||1.5–1.11: allows the deletion or undeletion of pages.
1.12+: allows the deletion of pages. For undeletions, there is now the 'undelete' right, see below.
|bigdelete||allows deletion of pages with larger than $wgDeleteRevisionsLimit revisions||1.12+|
|deletedhistory||allows viewing deleted history entries, but not seeing or restoring revisions||1.6+|
|deletedtext||allows viewing deleted revisions, but not restoring.|
|undelete||allows the undeletion of pages.||1.12+|
|browsearchive||allows prefix searching for titles of deleted pages through Special:Undelete.||1.13+|
|mergehistory||allows access to Special:MergeHistory, to merge non-overlapping pages.||1.12+|
|protect||allows locking a page to prevent edits and moves, and editing or moving locked pages. Is required to edit pages with cascading full protection.||1.5+|
|block||allows the blocking of IP addresses, CIDR ranges, and registered users. Block options include preventing editing and registering new accounts, and autoblocking other users on the same IP address.||1.5+|
|blockemail||allows preventing use of the Special:Emailuser interface when blocking.||1.11+|
|hideuser||allows hiding the user/IP from the block log, active block list, and user list when blocking. (not available by default)||1.10+|
|unblockself||allows a user to use the block interface to unblock themselves. Without it an administrator that has the capability to block cannot unblock themselves if blocked by another administrator.||1.17+|
|userrights||allows the use of the user rights interface, which allows the assignment or removal of all* groups to any user.
* With $wgAddGroups and $wgRemoveGroups you can set the possibility to add/remove certain groups instead of all.
|userrights-interwiki||allows changing user rights on other wikis.||1.12+|
|rollback||allows one-click reversion of edits.||1.5+|
|markbotedits||allows rollback to be marked as bot edits (see Manual:Administrators#Rollback).||1.12+|
|patrol||allows marking edits as legitimate ($wgUseRCPatrol must be true).||1.5+|
|patrolmarks||allows anons to see what was patrolled||1.16+|
|changetags||allows to add, change and remove tags, which aren't currently used by extenions||1.25+|
|editcontentmodel||allows changing the content model while editing a page.||1.23.7+|
|editinterface||allows editing the MediaWiki namespace, which contains interface messages.||1.5+|
|allows editing *.css / *.js subpages of any user. Split into editusercss and edituserjs in 1.16 and deprecated, but retained for backward compatibility.||1.12+|
|editusercss||allows editing *.css subpages of any user.||1.16+|
|edituserjs||allows editing *.js subpages of any user.||1.16+|
|editmyusercss||controls whether a user may edit their own CSS subpages.||1.22+|
|editmyuserjs||controls whether a user may edit their own JS subpages.||1.22+|
|editmywatchlist||controls whether a user may edit their watchlist.||1.22+|
|viewmywatchlist||controls whether a user may view their watchlist.||1.22+|
|editmyprivateinfo||controls whether a user may change their private information.||1.22+|
|viewmyprivateinfo||controls whether a user may access their private information.||1.22+|
|editmyoptions||controls whether a user may change their preferences.||1.22+|
|suppressrevision||allows preventing deleted revision information from being viewed by sysops and prevents sysops from undeleting the hidden info. Prior to 1.13 this right was named hiderevision (not available by default)||1.6+|
|viewsuppressed||allows viewing suppressed revision information but not actually (un)suppressing it; i.e. a more narrow alternative to "suppressrevision" (not available by default)||1.24+|
|deletelogentry||allows deleting/undeleting information (action text, summary, user who made the action) of specific log entries (not available by default)||1.20+|
|deleterevision||allows deleting/undeleting information (revision text, edit summary, user who made the edit) of specific revisions. Split into deleterevision and deletelogentry in 1.20 (not available by default)||1.6+|
|siteadmin||allows locking and unlocking the database (which blocks all interactions with the web site except viewing). Deprecated by default.||1.5+|
|import||allows user to import one page per time from another wiki ("transwiki").||1.5+|
|importupload||allows user to import several pages per time from XML files. This right was called 'importraw' in and before version 1.5.||1.5+|
|Obsolete. Allows removal of trackbacks (if $wgUseTrackbacks is true)||1.7 - 1.18|
|unwatchedpages||allows access to Special:Unwatchedpages, which lists pages that no user has watchlisted.||1.6+|
|managechangetags||allows to create and delete tags, which aren't currently used by extenions||1.25+|
|bot||hides edits from recent changes lists and watchlists by default (can optionally be viewed).||1.5+|
|purge||allows purging a page without a confirmation step (URL parameter "
|minoredit||allows marking an edit as 'minor'.||1.6+|
|nominornewtalk||blocks new message notification when making minor edits to user talk pages (requires minor edit right).||1.9+|
|noratelimit||not affected by rate limits (prior to the introduction of this right, the configuration variable $wgRateLimitsExcludedGroups was used for this purpose)||1.13+|
|ipblock-exempt||makes user immune to blocks applied to his IP address or a range (CIDR) containing it.||1.9+|
|proxyunbannable||makes user immune to the DNS proxy blacklist $wgEnableDnsBlacklist and local proxy blacklist $wgProxyList.||1.7+|
|autopatrol||automatically marks all edits by the user as patrolled ($wgUseRCPatrol must be true).||1.9+|
|apihighlimits||allows user to use higher limits for API queries||1.12+|
|writeapi||controls access to the write API ($wgEnableWriteAPI must be true)||1.13+|
|suppressredirect||Allows moving a page without automatically creating a redirect.||1.12+|
|autoconfirmed||used for the 'autoconfirmed' group, see the other table below for more information.||1.6+|
|Obsolete. Was used for the 'emailconfirmed' group, see the other table below for more information.||1.7 - 1.13|
List of groups[edit | edit source]
The following groups are available in the latest version of MediaWiki. If you are using an older version then some of these may not be implemented.
|*||all users (including anonymous).||1.5+|
|autoconfirmed||registered accounts at least as old as $wgAutoConfirmAge and having at least as many edits as $wgAutoConfirmCount.||1.6+|
|Obsolete, but $wgEmailAuthentication still exists. Registered accounts with confirmed email addresses.||1.7 - 1.13|
|bot||accounts with the bot right (intended for automated scripts).||1.5+|
|sysop||users who by default can delete and restore pages, block and unblock users, et cetera.||1.5+|
|bureaucrat||users who by default can change other users' rights.||1.5+|
|developer||A group for the 'siteadmin' right. The group is deprecated by default, as well as the right.||1.5|
From MW 1.12, you can create your own groups into which users are automatically promoted (as with autoconfirmed and emailconfirmed) using $wgAutopromote. You can even create any custom group by just assigning rights to them.
Default rights[edit | edit source]
The default rights are defined in DefaultSettings.php.
- Default values in HEAD version: 
- The default values in the latest stable MediaWiki release, version 1.24, are available here.
Adding new rights[edit | edit source]
Information for coders only follows.
If you're adding a new right in core, for instance to control a new special page, you are required to add it to the list of available rights in User.php,
$mCoreRights (example). If you're doing so in an extension, you instead need to use $wgAvailableRights.
You probably also want to also assign it to some user group by editing $wgGroupPermissions described above.
You also need to add
action-[name] interface messages to /languages/i18n/en.json (with documentation in qqq.json). The right-* messages can be seen on Special:ListGroupRights and the action-* messages are used in a sentence like "You do not have permission to ...".
See also[edit | edit source]
- Special:ListGroupRights - links to this help page and might contain not yet documented rights
- Help:Assigning permissions - help page describing use of the Special:Userrights interface (for bureaucrats)
- Manual:Setting user groups in MediaWiki - information about managing and the assignment of user groups.
- Manual:$wgAddGroups, Manual:$wgRemoveGroups
- Manual:Preventing access (examples)
- Manual:Establishing a hierarchy of bureaucrats
- Category:User rights extensions - Many extensions relating to user rights
|Log actions||Events: Blocking – Importing – Merging histories – Page deletion – Page moving – Page restoration – Patrolling – Protection – Renaming a user – RevisionDelete – Thanking – Uploading – User creation – User rights management
Miscellaneous: API – logging table – Null revision
|Language:||English • Deutsch • español • français • Bahasa Indonesia • 日本語 • 한국어 • português do Brasil|