User rights are permissions (such as the ability to edit pages or to block users) that can be assigned to differentuser groups.MediaWiki ships with a default set of user rights and user groups, but these can be customized.This page explains the default rights and groups, and how to customize them.
For information about how to add and remove individual wiki users from groups, seeHelp:User rights and groups andManual:Setting user groups in MediaWiki.
A default MediaWiki installation assigns certain rights to default groups (see table at#List of permissions).You can change the default rights by editing the$wgGroupPermissions array inLocalSettings.php with the following syntax:
$wgGroupPermissions['group']['right']=true/* or false */;
$wgGroupPermissions will be set inincludes/DefaultSettings.php, but it isnot present inLocalSettings.php. You will then need to add it in that file.If a member has multiple groups, they get all 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.
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 withconfirmed email 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 email 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;
You can create new user groups by defining permissions for the according group name in$wgGroupPermissions['group-name' ] wheregroup-name is the actual name of the group.
Additionally to assigning permissions, you should create these three wiki pages with fitting content:
Name of the group)Name of a member of the group)Name of the group page)By default, bureaucrats can add users to, or remove them from, any group.However, if you are using$wgAddGroups and$wgRemoveGroups, you may need to customize those instead.
This example will create an arbitraryprojectmember group that can block users and delete pages, and whose edits are hidden by default in the recent changes log:
$wgGroupPermissions['projectmember']['bot']=true;$wgGroupPermissions['projectmember']['block']=true;$wgGroupPermissions['projectmember']['delete']=true;
'random-group' or'random_group' instead of'random group'. Moreover it is recommended to only use lowercase letters to create a group.In this example, you would probably also want to create these pages:
Project members)Project member)Project:Project Members)This will ensure that the group will be referred to as "Project members" throughout the interface, and a member will be referred to as a "Project member", and overviews will link the group name toProject:Project members.
This example disables write access (page editing and creation) by default, creates a group namedwriter, and grants it write access.Users can be manually added to this group viaSpecial:UserRights:
$wgGroupPermissions['*']['edit']=false;$wgGroupPermissions['*']['createpage']=false;$wgGroupPermissions['user']['edit']=false;$wgGroupPermissions['user']['createpage']=false;$wgGroupPermissions['writer']['edit']=true;$wgGroupPermissions['writer']['createpage']=true;
In this example, you would probably also want to create these pages:
Writers)Writer)Project:Write)MediaWiki out of the box comes with a number of predefined groups.Most of these groups can be removed by unsetting the according array keys, among them$wgGroupPermissions['<group-name>' ].For details, see below.
This example will eliminate thebureaucrat 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 atSpecial:ListGroupRights; however, merely unsetting$wgGroupPermissions will suffice to remove it fromSpecial:UserRights.
unset($wgGroupPermissions['bureaucrat']);unset($wgRevokePermissions['bureaucrat']);unset($wgAddGroups['bureaucrat']);unset($wgRemoveGroups['bureaucrat']);unset($wgGroupsAddToSelf['bureaucrat']);unset($wgGroupsRemoveFromSelf['bureaucrat']);
This code will not work if any extension that modifies the default rights for thebureaucrat group, such asExtension:AntiSpoof, is installed.
More broadly, to disable a user group created by an extension, the above code needs to run after all extensions have been registered.This used to be possible by registering an extension function inLocalSettings.php:
$wgExtensionFunctions[]=function()use(&$wgGroupPermissions){unset($wgGroupPermissions['oversight']);unset($wgGroupPermissions['flow-bot']);};
However, thisno longer works reliably due toT275334.
With the above mechanism, you can remove the groupssysop,bureaucrat,bot,interface-admin,suppress, which - if used - can be assigned through the usualuser permission system.However, it is currently impossible to remove theuser group.This group isnot assigned through the usual permission system.Instead, every registered user automatically is a member of that group.This is hardcoded in MediaWiki and currently cannot be changed easily.
The following user rights are available in the latest version of MediaWiki.If you are using an older version, look atSpecial:Version on your wiki and see if your version is covered in the "Versions" column.
| Right | Description | User groups that have this right by default | Versions |
|---|---|---|---|
| Reading | |||
| read | Read pages - when set tofalse, override for specific pages with$wgWhitelistReadSetting theuser right 'read' tofalse only restricts access to wiki pages (such as articles and talk pages).Uploaded files (including images, files, docs) under the$wgUploadPath subdirectories willalways remain publicly accessible via direct URL access by default.To restrict access to uploaded files, refer to the instructions inManual:Image authorization andimg_auth.php. | *, user | 1.5+ |
| Editing | |||
| applychangetags | Applytags along with one's changes - requires theedit right | user | 1.25+ |
| autocreateaccount | Automatically log in with an external user account - a more limited version ofcreateaccount | — | 1.27+ |
| createaccount | Create new user accounts - register / registration | *, sysop | 1.5+ |
| createpage | Create pages (which are not discussion pages) - requires theedit right | *, user | 1.6+ |
| createtalk | Create discussion pages - requires theedit right | *, user | 1.6+ |
| delete-redirect | Delete single revision redirects (note that this is not needed if the group already has thedelete right) | — | 1.36+ |
| edit | Edit pages - requires theread right | *, user | 1.5+ |
| editsemiprotected | Edit pages protected as "Allow only autoconfirmed users" - without cascading protection - requires theedit right | autoconfirmed, bot, sysop | 1.22+ |
| editprotected | Edit pages protected as "Allow only administrators" - without cascading protection - requires theedit right | sysop | 1.13+ |
| minoredit | Mark edits as minor - requires theedit right | user | 1.6+ |
| move | Move pages - requires theedit right | user, sysop | 1.5+ |
| move-categorypages | Move category pages - requires themove right | user, sysop | 1.25+ |
| move-rootuserpages | Move root user pages - requires themove right | user, sysop | 1.14+ |
| move-subpages | Move pages with their subpages - requires themove right | user, sysop | 1.13+ |
| movefile | Move files - requires themove right as well | user, sysop | 1.14+ |
| reupload | Overwrite existing files - requires theupload right | user, sysop | 1.6+ |
| reupload-own | Overwrite existing files uploaded by oneself - requires theupload right (note that this is not needed if the group already has thereupload right) | — | 1.11+ |
| reupload-shared | Override files on the shared media repository locally - (if one is set up) with local files (requires theupload right) | user, sysop | 1.6+ |
| sendemail | Send email to other users | user | 1.16+ |
| upload | Upload files - requires theedit right and$wgEnableUploads to be true | user, sysop | 1.5+ |
| upload_by_url | Upload files from a URL - requires theupload right (Prior to 1.20 it was given to sysops) | — | 1.8+ |
| Management | |||
| bigdelete | Delete pages with large histories (as determined by$wgDeleteRevisionsLimit) - requires thedelete right | sysop | 1.12+ |
| block | Block or unblock other users from editing - Block options include preventing editing and registering new accounts, and autoblocking other users on the same IP address | sysop | 1.5+ |
| blockemail | Block or unblock a user from sending email - allows preventing use of theSpecial:Emailuser interface when blocking - requires theblock right | sysop | 1.11+ |
| browsearchive | Search deleted pages - throughSpecial:Undelete - requires thedeletedhistory right | sysop | 1.13+ |
| changetags | Add and remove arbitrarytags on individual revisions and log entries - currently unused by extensions | user | 1.25+ |
| delete | Delete pages1.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 | sysop | 1.5+ |
| deletedhistory | View deleted history entries, without their associated text | sysop | 1.6+ |
| deletedtext | View deleted text and changes between deleted revisions | sysop | 1.16+ |
| deletelogentry | Delete and undelete specific log entries - allows deleting/undeleting information (action text, summary, user who made the action) of specific log entries - requires thedeleterevision right | suppress | 1.20+ |
| deleterevision | Delete and undelete specific revisions of pages - allows deleting/undeleting information (revision text, edit summary, user who made the edit) of specific revisions(Split intodeleterevision anddeletelogentry in 1.20) | suppress | 1.6+ |
| editcontentmodel | Edit the content model of a page - requires theedit right | user | 1.23.7+ |
| editinterface | Edit the user interface - containsinterface messages. For editing sitewide CSS/JSON/JS, there are now segregate rights, see below. - requires theedit right | sysop, interface-admin | 1.5+ |
| editmyoptions | Edit your own preferences | * | 1.22+ |
| editmyprivateinfo | Edit your own private data (e.g. email address, real name) and request password reset emails - also hides the "Change Password", but not other ways to change the password - requires theviewmyprivateinfo right | * | 1.22+ |
| editmyusercss | Edit your own user CSS files - prior to 1.31 it was assigned to everyone (i.e. "*") (note that this is not needed if the group already has theeditusercss right) - requires theedit right | user | 1.22+ |
| editmyuserjs | Edit your own user JavaScript files - prior to 1.31 it was assigned to everyone (i.e. "*") (note that this is not needed if the group already has theedituserjs right) - requires theedit right | user | 1.22+ |
| editmyuserjsredirect | Edit your own user JavaScript files that are redirects (note that this is not needed if the group already has theedituserjs right) - requires theedit right | — | 1.34+ |
| editmyuserjson | Edit your own user JSON files (note that this is not needed if the group already has theedituserjson right) - requires theedit right | user | 1.31+ |
| editmywatchlist | Edit your own watchlist (note that some actions will still add pages even without this right) - requires theviewmywatchlist right | user | 1.22+ |
| editsitecss | Edit sitewide CSS - requires theeditinterface right | interface-admin | 1.32+ |
| editsitejs | Edit sitewide JavaScript - requires theeditinterface right | interface-admin | 1.32+ |
| editsitejson | Edit sitewide JSON - requires theeditinterface right | sysop, interface-admin | 1.32+ |
| editusercss | Edit other users' CSS files - requires theedit right | interface-admin | 1.16+ |
| edituserjs | Edit other users' JavaScript files - requires theedit right | interface-admin | 1.16+ |
| edituserjson | Edit other users' JSON files - requires theedit right | sysop, interface-admin | 1.31+ |
| hideuser | Block or unblock a username, hiding or unhiding it from the public - Only users with 1000 edits or less can be suppressed by default - requires theblock right Use | suppress | 1.10+ |
| markbotedits | Mark rolled-back edits as bot edits - seeManual:Rollback - requires therollback right | sysop | 1.12+ |
| mergehistory | Merge the history of pages - requires theedit right | sysop | 1.12+ |
| pagelang | Change page language -$wgPageLanguageUseDB must betrue | — | 1.24+ |
| patrol | Mark others' edits as patrolled -$wgUseRCPatrol must betrue | sysop | 1.5+ |
| patrolmarks | View recent changes patrol marks (note that this is not needed if the group already has thepatrol right) | — | 1.16+ |
| protect | Change protection settings and edit cascade-protected pages - requires theedit right | sysop | 1.5+ |
| rollback | Quickly rollback the edits of the last user who edited a particular page - requires theedit right | sysop | 1.5+ |
| suppressionlog | View private logs | suppress | 1.6+ |
| suppressrevision | View, hide and unhide specific revisions of pages from any user -Prior to1.13 this right was named hiderevision - requires thedeleterevision right | suppress | 1.6+ |
| unblockself | Unblock oneself - Without it, an administrator that has the capability to block cannot unblock themselves if blocked by another administrator | sysop | 1.17+ |
| undelete | Undelete a page - requires thedeletedhistory right | sysop | 1.12+ |
| userrights | Edit all user rights - 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 | bureaucrat | 1.5+ |
| userrights-interwiki | Edit user rights of users on other wikis - requires theuserrights right | — | 1.12+ |
| viewmyprivateinfo | View your own private data (e.g. email address, real name) | * | 1.22+ |
| viewmywatchlist | View your own watchlist | user | 1.22+ |
| viewsuppressed | View revisions hidden from any user - i.e. a more narrow alternative to "suppressrevision" (note that this is not needed if the group already has thesuppressrevision right) | suppress | 1.24+ |
| Administration | |||
| autopatrol | Have one's own edits automatically marked as patrolled -$wgUseRCPatrol must betrue | bot, sysop | 1.9+ |
| deletechangetags | Deletetags from the database - currently unused by extensions | sysop | 1.28+ |
| import | Import pages from other wikis - "transwiki" - requires theedit right | sysop | 1.5+ |
| importupload | Import pages from a file upload - This right was called 'importraw' in and before version 1.5 - requires theedit right | sysop | 1.5+ |
| managechangetags | Create and (de)activatetags - currently unused by extensions | sysop | 1.25+ |
| renameuser | Rename users (formerly was part of the Renameuser extension) | bureaucrat | 1.40+ |
| siteadmin | Lock and unlock the database - which blocks all interactions with the web site except viewing. (not available by default) | — | 1.5+ |
| unwatchedpages | View a list of unwatched pages - lists pages that no user has watchlisted | sysop | 1.6+ |
| Technical | |||
| apihighlimits | Use higher limits in API queries | bot, sysop | 1.12+ |
| autoconfirmed | Not be affected by IP-based rate limits - used for the 'autoconfirmed' group, see the other table below for more information (note that this is not needed if the group already has thenoratelimit right) | autoconfirmed, bot, sysop | 1.6+ |
| bot | Be treated as an automated process - edits and logged actions are hidden from recent changes. can optionally be viewed | bot | 1.5+ |
| ipblock-exempt | Bypass IP blocks, auto-blocks and range blocks | sysop | 1.9+ |
| nominornewtalk | Not have minor edits to discussion pages trigger the new messages prompt - requires theminoredit right | bot | 1.9+ |
| noratelimit | Not be affected by rate limits - not affected byrate limits (prior to the introduction of this right, the configuration variable$wgRateLimitsExcludedGroups was used for this purpose) | sysop, bureaucrat | 1.13+ |
| override-export-depth | Export pages including linked pages up to a depth of 5 With this right, you can define the depth of linked pages atSpecial:Export. Otherwise, the value of$wgExportMaxLinkDepth, which is 0 by default, will be used. | — | 1.15+ |
| suppressredirect | Not create redirects from source pages when moving pages - requires themove right | bot, sysop | 1.12+ |
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.
| Group | Description | Default rights | Versions |
|---|---|---|---|
| * | All users (including anonymous). | createaccount, createpage, createtalk, edit, editmyoptions, editmyprivateinfo, read, viewmyprivateinfo | 1.5+ |
| temp | Temporary user accounts (T330816) | Similar to* group | 1.41+ |
| user | Registered accounts. Doesnot include temporary accounts. | applychangetags, changetags, createpage, createtalk, edit, editcontentmodel, editmyusercss, editmyuserjs, editmyuserjson, editmywatchlist, minoredit, move, move-categorypages, move-rootuserpages, move-subpages, movefile, purge, read, reupload, reupload-shared, sendemail, upload, viewmywatchlist | 1.13+ |
| autoconfirmed | Registered accounts at least as old as$wgAutoConfirmAge and having at least as many edits as$wgAutoConfirmCount. | autoconfirmed, editsemiprotected | 1.6+ |
| bot | Accounts with thebot right (intended for automated scripts). | autoconfirmed, autopatrol, apihighlimits, bot, editsemiprotected, nominornewtalk, suppressredirect | 1.5+ |
| sysop | Users who by default can delete and restore pages, block and unblock users, etc. | apihighlimits, autoconfirmed, autopatrol, bigdelete, block, blockemail, browsearchive, createaccount, delete, deletedhistory, deletedtext, editinterface, editprotected, editsemiprotected, editsitejson, edituserjson, import, importupload, ipblock-exempt, managechangetags, markbotedits, mergehistory, move, move-categorypages, move-rootuserpages, move-subpages, movefile, noratelimit, patrol, protect, reupload, reupload-shared, rollback, suppressredirect, unblockself, undelete, unwatchedpages, upload | 1.5+ |
| interface-admin | Users who can edit sitewide CSS/JS. | editinterface, editsitecss, editsitejs, editsitejson, editusercss, edituserjs, edituserjson | 1.32+ |
| bureaucrat | Users who can change the rights of other users by default and therefore have full access of the entire wiki. | noratelimit, renameuser, userrights | 1.5+ |
| suppress | deletelogentry, deleterevision, hideuser, suppressionlog, suppressrevision, viewsuppressed | 1.13+ |
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.
The default rights are defined inMainConfigSchema.php.
PermissionManager::getAllRights().Information for coders only follows.
If you're adding a new right in core, for instance tocontrol a new special page, you arerequired to add it to the list of available rights inPermissionManager.php,$coreRights (example).If you'redoing so in an extension, you instead need to use$wgAvailableRights.
You probably also want to assign it to some user group by editing$wgGroupPermissions described above.
If you want this right to be accessible to external applications byOAuth or bybot passwords, then you will need to add it to a grant by editing$wgGrantPermissions.
// create projectmember-powers right$wgAvailableRights[]='projectmember-powers';// add projectmember-powers to the projectmember-group$wgGroupPermissions['projectmember']['projectmember-powers']=true;// add projectmember-powers to the 'basic' grant so we can use our projectmember powers over an API request$wgGrantPermissions['basic']['projectmember-powers']=true;
You also need to addright-[name] andaction-[name] interface messages to /languages/i18n/en.json (with documentation in qqq.json).The right-* messages can be seen onSpecial:ListGroupRights and the action-* messages are used in a sentence like "You do not have permission to ...".