Manual:User rights - MediaWiki
Jump to content
From mediawiki.org
Translate this page
Languages:
Bahasa Indonesia
Türkçe
català
dansk
italiano
kabuverdianu
polski
português
português do Brasil
suomi
svenska
čeština
русский
српски / srpski
українська
עברית
العربية
فارسی
کوردی
हिन्दी
ไทย
ဘာသာမန်
中文
ꯃꯤꯇꯩ ꯂꯣꯟ
한국어
User rights
are permissions (such as the ability to edit pages or to block users) that can be assigned to different
user 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, see
Help:User rights and groups
and
Manual:Setting user groups in MediaWiki
Changing group permissions
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 in
LocalSettings.php
with the following syntax:
$wgGroupPermissions
'group'
][
'right'
true
/* or false */
In a default installation
$wgGroupPermissions
will be set in
includes/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 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
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 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
Creating a new group and assigning permissions to it
Custom groups can be created. A group is created implicitly, by just assigning it rights in
$wgGroupPermissions
group-name'
where
group-name
is the actual name of the group.
From MW 1.12, you can create your own groups into which users are automatically promoted (as with
autoconfirmed
) using
$wgAutopromote
Additionally to assigning permissions, you should create these three wiki pages with fitting content:
MediaWiki:Group-
(content:
Name of the group
MediaWiki:Group-
(content:
Name of a member of the group
MediaWiki:Grouppage-
(content:
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.
Examples
This example will create an arbitrary
projectmember
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
The group name cannot contain spaces, so use
'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:
MediaWiki:Group-projectmember
(content:
Project members
MediaWiki:Group-projectmember-member
(content:
Project member
MediaWiki:Grouppage-projectmember
(content:
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 to
Project:Project members
This example disables write access (page editing and creation) by default, creates a group named
writer
, 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
'writer'
][
'edit'
true
$wgGroupPermissions
'writer'
][
'createpage'
true
In this example, you would probably also want to create these pages:
MediaWiki:Group-writer
(content:
Writers
MediaWiki:Group-writer-member
(content:
Writer
MediaWiki:Grouppage-writer
(content:
Project:Write
List of permissions
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.
Right
Description
User groups that have this right by default
Versions
Reading
read
Read pages – when set to
false
, override for specific pages with
$wgWhitelistRead
Setting the
user right
'read'
to
false
only restricts access to wiki pages (such as articles and talk pages).
Uploaded files (including images, files, docs) under the
$wgUploadPath
subdirectories will
always
remain publicly accessible via direct URL access by default.
To restrict access to uploaded files, refer to the instructions in
Manual:Image authorization
and
img_auth.php
*, user
1.5+
Editing
applychangetags
Apply
tags
along with one's changes – requires the
edit
right
user
1.25+
autocreateaccount
Automatically log in with an external user account - a more limited version of
createaccount
1.27+
createaccount
Create new user accounts – register / registration
*, sysop
1.5+
createpage
Create pages (which are not discussion pages) – requires the
edit
right
*, user
1.6+
createtalk
Create discussion pages – requires the
edit
right
*, user
1.6+
delete-redirect
Delete single revision redirects (note that this is not needed if the group already has the
delete
right)
1.36+
edit
Edit pages – requires the
read
right
*, user
1.5+
editsemiprotected
Edit protected pages (semi protected) – without cascading protection – requires the
edit
right
autoconfirmed, bot, sysop
1.22+
editprotected
Edit protected pages (fully protected) – without cascading protection – requires the
edit
right
sysop
1.13+
minoredit
Mark edits as minor – requires the
edit
right
user
1.6+
move
Move pages – requires the
edit
right
user, sysop
1.5+
move-categorypages
Move category pages – requires the
move
right
user, sysop
1.25+
move-rootuserpages
Move root user pages – requires the
move
right
user, sysop
1.14+
move-subpages
Move pages with their subpages – requires the
move
right
user, sysop
1.13+
movefile
Move files – requires the
move
right as well
user, sysop
1.14+
reupload
Overwrite existing files – requires the
upload
right
user, sysop
1.6+
reupload-own
Overwrite existing files uploaded by oneself – requires the
upload
right (note that this is not needed if the group already has the
reupload
right)
1.11+
reupload-shared
Override files on the shared media repository locally – (if one is set up) with local files (requires the
upload
right)
user, sysop
1.6+
sendemail
Send email to other users
user
1.16+
upload
Upload files – requires the
edit
right and
$wgEnableUploads
to be
true
user, sysop
1.5+
upload_by_url
Upload files from a URL – requires the
upload
right (Prior to 1.20 it was given to sysops)
1.8+
Management
autopatrol
Modifies certain actions performed by the permission holder, automatically marking them as
"patrolled"
– Depends on
$wgUseRCPatrol
$wgUseNPPatrol
$wgUseFilePatrol
bot, sysop
1.9+
bigdelete
Delete pages with large histories (as determined by
$wgDeleteRevisionsLimit
) – requires the
delete
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 the
Special:Emailuser
interface when blocking – requires the
block
right
sysop
1.11+
browsearchive
Search deleted pages – through
Special:Undelete
– requires the
deletedhistory
right
sysop
1.13+
changetags
Add and remove arbitrary
tags
on individual revisions and log entries – currently unused by extensions
user
1.25+
delete
Delete pages
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)
sysop
1.5+
deletedhistory
View deleted history entries, without their associated text
sysop
1.6+
deletedtext
View deleted text and changes between deleted revisions – requires the
deletedhistory
right
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 the
deleterevision
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 into
deleterevision
and
deletelogentry
in 1.20)
suppress
1.6+
editcontentmodel
Edit the content model of a page – requires the
edit
right
user
1.23.7+
editinterface
Edit the user interface – contains
interface messages
. For editing sitewide CSS/JSON/JS, there are now segregate rights, see below. – requires the
edit
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 the
viewmyprivateinfo
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 the
editusercss
right) – requires the
edit
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 the
edituserjs
right) – requires the
edit
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 the
edituserjs
right) – requires the
edit
right
1.34+
editmyuserjson
Edit your own user JSON files (note that this is not needed if the group already has the
edituserjson
right) – requires the
edit
right
user
1.31+
editmywatchlist
Edit your own watchlist (note that some actions will still add pages even without this right) – requires the
viewmywatchlist
right
user
1.22+
editsitecss
Edit sitewide CSS – requires the
editinterface
right
interface-admin
1.32+
editsitejs
Edit sitewide JavaScript – requires the
editinterface
right
interface-admin
1.32+
editsitejson
Edit sitewide JSON – requires the
editinterface
right
sysop, interface-admin
1.32+
editusercss
Edit other users' CSS files – requires the
edit
right
interface-admin
1.16+
edituserjs
Edit other users' JavaScript files – requires the
edit
right
interface-admin
1.16+
edituserjson
Edit other users' JSON files – requires the
edit
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 the
block
right
Use
$wgHideUserContribLimit
to disable.
suppress
1.10+
ignore-restricted-groups
Bypass conditions on editing certain restricted user groups – Only applies to groups the user would be otherwise able to change, based on
userrights
right and the contents of
$wgAddGroups
1.46+
markbotedits
Mark rolled-back edits as bot edits – see
Manual:Rollback
– requires the
rollback
right
sysop
1.12+
mergehistory
Merge the history of pages – requires the
edit
right
sysop
1.12+
pagelang
Change page language –
$wgPageLanguageUseDB
must be
true
1.24+
patrol
Mark certain actions as
"patrolled"
– depends on
$wgUseRCPatrol
$wgUseNPPatrol
$wgUseFilePatrol
sysop
1.5+
patrolmarks
View recent changes patrol marks (note that this is not needed if the group already has the
patrol
right)
1.16+
protect
Change protection settings and edit cascade-protected pages – requires the
edit
right
sysop
1.5+
rollback
Quickly rollback the edits of the last user who edited a particular page
– requires the
edit
right
sysop
1.5+
suppressionlog
View private logs
suppress
1.6+
suppressrevision
View, hide and unhide specific revisions of pages from any user –
Prior to
1.13
this right was named
hiderevision
– requires the
deleterevision
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 the
deletedhistory
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 the
userrights
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 the
suppressrevision
right)
suppress
1.24+
Administration
deletechangetags
Delete
tags
from the database – currently unused by extensions
sysop
1.28+
import
Import pages from other wikis – "transwiki" – requires the
edit
right
sysop
1.5+
importupload
Import pages from a file upload – This right was called
importraw
in and before version 1.5 – requires the
edit
right
sysop
1.5+
managechangetags
Create and (de)activate
tags
– 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 the
noratelimit
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 the
minoredit
right
bot
1.9+
noratelimit
Not be affected by rate limits – not affected by
rate 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 at
Special: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 the
move
right
bot, sysop
1.12+
Although these permissions all control separate things, sometimes to perform certain actions you need multiple permissions. For example allowing people to edit but not read pages doesn't make sense, since in order to edit a page you must first be able to read it (Assuming no pages are allowlisted). Allowing uploads but not editing does not make sense, since in order to upload an image you must implicitly create an image description page, etc.
Predefined groups
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. Does
not
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 the
bot
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 and JavaScript.
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+
Removing predefined groups
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.
Example
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:ListGroupRights
; however, merely unsetting
$wgGroupPermissions
will suffice to remove it from
Special: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 the
bureaucrat
group, such as
Extension:AntiSpoof
, is installed.
Tracked in
Phabricator
Task T275334
Open
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 in
LocalSettings.php
$wgExtensionFunctions
[]
function
()
use
$wgGroupPermissions
unset
$wgGroupPermissions
'oversight'
);
unset
$wgGroupPermissions
'flow-bot'
);
};
However, this
no longer works reliably
due to
T275334
Note on the group called
user
With the above mechanism, you can remove the groups
sysop
bureaucrat
bot
interface-admin
suppress
, which - if used - can be assigned through the usual
user permission system
However, it is currently impossible to remove the
user
group.
This group is
not
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.
Default rights
The default rights are defined in
MainConfigSchema.php
Default values in the current alpha version (HEAD, version 1.46)
Default values in the latest stable version (branch REL1_45, version 1.45)
Additional rights: you should be able to list all the permissions available on your wiki by running
PermissionManager
::
getAllRights
()
Adding new rights
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
PermissionManager.php
$coreRights
example
).
If you're
doing so in an extension
, you instead need to use
$wgAvailableRights
, or preferably define the right in
extensions.json
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 by
OAuth
or by
bot 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 add
right-[name]
and
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
Special:ListGroupRights
– Links to this help page and might contain not yet documented rights
Help:User rights and groups
– 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:$wgNamespaceProtection
Manual:$wgAutopromote
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 undeletion
Patrolling
Protection
Renaming a user
RevisionDelete
Thanking
Uploading
User creation
User rights management
Merging users
Settings
$wgLogTypes
$wgLogActions
$wgLogNames
$wgLogHeaders
$wgLogActionsHandlers
$wgLogRestrictions
$wgFilterLogTypes
$wgActionFilteredLogs
Miscellaneous
Logging to Special:Log
API
logging
table
Dummy revision
Retrieved from "
Categories
Special Pages
Permission
Manual
User rights
Add topic
US