Help:User rights

A new feature of MediaWiki, which is available in the 1.5 versions allows user groups to be created and modified. To change the groups to which a user belongs, use Special:Userrights. Each group can be assigned a mixture of the following rights (permissions). If you are using 1.3 or 1.4, have a look at setting user rights in MediaWiki instead.

Available rights

read: Allows users to read pages not in $wgWhitelistRead
edit: Allows editing of any page which is not protected
createpage: Allows creating normal pages
createtalk: Allows creating talk pages. Note that edit = false prevents creating talk page regardless of this setting.
move: Lets users change the title of a page by moving it
delete: Lets a user delete a page
undelete: Lets a user view deleted versions, undelete a previously deleted page, or undelete specific revisions of a deleted page
protect: Lets users lock a page (presumably only those with the ability to protect a page can edit a protected page)
block: Enables a user to block an IP address, user name, or range of IPs, from editing
userrights: Lets a user change the access levels of another user including de-sysopping. On wikipedia a Steward is required for this, but by default in mediawiki it requires only bureaucrat. Steward isn't a default group.
createaccount: Lets a user create a user account for another user, or for themselves
upload: Lets a user upload an image or other file to the wiki, or to overwrite an existing non-protected file
rollback: Gives a user a link to more easily revert a bad edit
patrol: Lets a user state that they have checked an edit that appeared in recent changes
editinterface: Lets users edit the MediaWiki namespace to affect the interface
siteadmin: Lets users lock and unlock the database (and possibly change other settings that affect the whole site)
bot: Edits by a user with this "right" (rather: property) by default do not show up in recent changes (usually only used for mass edits by bots)

Via extension

These aren't available in the main MediaWiki codebase:

asksql: Lets a user query the database using SQL (currently disabled)
checkuser: Lets a user find all the IP addresses used by a particular logged in user, and to show all the contributions from a given IP address, including those made by logged in users
makesysop: On the Wikimedia sites, the bureaucrat group has a restricted Special:Makesysop interface, while the steward group has the full Special:Userrights interface and an extended version
oversight: Lets a user move single revisions from the revision table to a special hidden table to hide it.
talk: Makes the editing of talk pages a distinct action from the editing of articles. See Talkright extension

Tree

autoconfirmed
bot
createaccount
emailconfirmed
proxyunbannable
read
- block
- delete (delete pages)
  - trackback
- deletedhistory
  - delete (show/restore deleted pages)
- deleterevision
- edit
  - createpage
  - createtalk
  - editinterface
  - minoredit
- hiderevision
- import
  - importupload
- move
- patrol
- protect
- rollback
- siteadmin
- unwatchedpages
- upload
  - reupload
  - reupload-shared
  - upload_by_url
- userrights

Changing user groups manually in the database

The user rights are in a table called user_groups with two fields called ug_user and ug_group. There must be one row inserted for each group the user belongs to. You must know the user id number of the user from the users table. This sql query should do the trick. In the example below substitute 1 with the user ID number from the users table.

INSERT INTO user_groups (ug_user, ug_group) VALUES ('1', 'bureaucrat'); 
INSERT INTO user_groups (ug_user, ug_group) VALUES ('1', 'sysop');

Managing group rights

To change the access levels of existing groups or add new groups, you need to have shell/ftp access to the machine that MediaWiki is running on. You can add or remove permissions to a group with the following sample statements in LocalSettings.php.

To disable account creation by anonymous visitors (this replaces $wgWhitelistAccount from 1.4)

 $wgGroupPermissions['*']['createaccount'] = false;

To require that users log in to edit (this replaces the $wgWhitelistEdit from 1.4):

 $wgGroupPermissions['*']['edit'] = false;

It's worth noting that if you set this, you may also want to set

$wgShowIPinHeader = false; # For non-logged in users

This removes the link to the talk page in the header for non-logged in users, and hasn't changed from 1.4.

If $wgWhitelistRead is set, you must also disable the 'read' permission for it to take effect on anonymous users. Any CSS and JS pages used in the Main Page or Login Page should be accessible as well to avoid IE scripting error dialog box.

 $wgWhitelistRead = array( "Main Page", "Special:Userlogin", "-", "MediaWiki:Monobook.css" );
 $wgGroupPermissions['*']['read'] = false;

Main Page is not mandatory for this list. To avoid "login required" redirect page, you can change includes/OutputPage.php loginToUse():

function loginToUse() {
    $titleObj = Title::makeTitle( NS_SPECIAL, "Userlogin" );
    $this->redirect( $titleObj->getFullURL() );
}

You can define new groups as well, and then assign them to users through Special:Userrights:

 $wgGroupPermissions['ninja']['delete'] = true;
 $wgGroupPermissions['ninja']['block'] = true;
 $wgGroupPermissions['ninja']['bot'] = true;

Defaults

For reference, here are the default group/permission assignments in 1.6.9, 1.8.2, 1.8.3, and 1.9.2 unless otherwise noted (found in includes/DefaultSettings.php):

/**
 * Permission keys given to users in each group.
 * All users are implicitly in the '*' group including anonymous visitors;
 * logged-in users are all implicitly in the 'user' group. These will be
 * combined with the permissions of all groups that a given user is listed
 * in in the user_groups table.
 *
 * Functionality to make pages inaccessible has not been extensively tested
 * for security. Use at your own risk!
 *
 * This replaces wgWhitelistAccount and wgWhitelistEdit
 */
$wgGroupPermissions = array();

// Implicit group for all anonymous
$wgGroupPermissions['*'    ]['createaccount']   = true;
$wgGroupPermissions['*'    ]['read']            = true;
$wgGroupPermissions['*'    ]['edit']            = true;
$wgGroupPermissions['*'    ]['createpage']      = true;
$wgGroupPermissions['*'    ]['createtalk']      = true;

// Implicit group for all logged-in accounts
$wgGroupPermissions['user' ]['move']            = true;
$wgGroupPermissions['user' ]['read']            = true;
$wgGroupPermissions['user' ]['edit']            = true;
$wgGroupPermissions['user' ]['createpage']      = true;
$wgGroupPermissions['user' ]['createtalk']      = true;
$wgGroupPermissions['user' ]['upload']          = true;
$wgGroupPermissions['user' ]['reupload']        = true;
$wgGroupPermissions['user' ]['reupload-shared'] = true;
$wgGroupPermissions['user' ]['minoredit']       = true;

// Implicit group for accounts that pass $wgAutoConfirmAge
$wgGroupPermissions['autoconfirmed']['autoconfirmed'] = true;

// Implicit group for accounts with confirmed email addresses
// This has little use when email address confirmation is off
$wgGroupPermissions['emailconfirmed']['emailconfirmed'] = true; // not in version 1.6.9

// Users with bot privilege can have their edits hidden
// from various log pages by default
$wgGroupPermissions['bot'  ]['bot']             = true;
$wgGroupPermissions['bot'  ]['autoconfirmed']   = true;
$wgGroupPermissions['bot'  ]['nominornewtalk']  = true; // not in version 1.6.9, 1.8.2, 1.8.3

// Most extra permission abilities go to this group
$wgGroupPermissions['sysop']['block']           = true;
$wgGroupPermissions['sysop']['createaccount']   = true;
$wgGroupPermissions['sysop']['delete']          = true;
$wgGroupPermissions['sysop']['deletedhistory']  = true; // can view deleted history entries, but not see or restore the text
$wgGroupPermissions['sysop']['editinterface']   = true;
$wgGroupPermissions['sysop']['import']          = true;
$wgGroupPermissions['sysop']['importupload']    = true;
$wgGroupPermissions['sysop']['move']            = true;
$wgGroupPermissions['sysop']['patrol']          = true;
$wgGroupPermissions['sysop']['autopatrol']	= true; // not in version 1.6.9, 1.8.2, 1.8.3
$wgGroupPermissions['sysop']['protect']         = true;
$wgGroupPermissions['sysop']['proxyunbannable'] = true; //not in version 1.6.9
$wgGroupPermissions['sysop']['rollback']        = true;
$wgGroupPermissions['sysop']['trackback']       = true; //not in version 1.6.9
$wgGroupPermissions['sysop']['upload']          = true;
$wgGroupPermissions['sysop']['reupload']        = true;
$wgGroupPermissions['sysop']['reupload-shared'] = true;
$wgGroupPermissions['sysop']['unwatchedpages']  = true;
$wgGroupPermissions['sysop']['autoconfirmed']   = true;
$wgGroupPermissions['sysop']['upload_by_url']   = true; //not in version 1.6.9
$wgGroupPermissions['sysop']['ipblock-exempt']	= true; // not in version 1.6.9, 1.8.2, 1.8.3

// Permission to change users' group assignments
$wgGroupPermissions['bureaucrat']['userrights'] = true;

Questions

How do you restrict non-logged to read pages?

I set $wgGroupPermissions['*'][read] = false;

then no one can even read the login page...

How do you create one or more new groups?

Just create an entry in $wgGroupPermissions['ninja']['read'] = true; , and the group Ninja should show up in Special:Userrights. (add it will be allow to read pages, of course.) Dto 22:32, 2 September 2006 (UTC)

Where are these and how does one change them?

mw:Help:Configuration settings

How do you restrict access to and download for images?

How do I protect a certain namespace from being viewed by * and user?

Preventing Access#Setting permissions for a Group on a whole new Namespace

How do I change user permissions?

To change which groups a user belongs to, a 'bureaucrat' should visit Special:Specialpages and click the link to 'User Rights Management' on the very bottom of the list which will bring them to Special:Userrights and follow the on-screen instructions.

This will only work for a bureaucrat unless you have changed your settings to function otherwise.

On some pages in MediaWiki project (www.mediawiki.org), I've seen that non-logged users cannot edit pages ("view source"), but can edit discussion pages. How do I do this in my wiki?

There's a hack shown at Mediawiki:Help:$wgWhitelistEdit, but it doesn't seem to work in version 1.6.5. I've been using the following hack. It goes in the file includes/User.php, in the function isAllowed($action=''). Here's the complete modified code for the function:

function isAllowed($action='') {
	if ( $action === '' )
		// In the spirit of DWIM
		return true;
	
	/* Special Cases */
	global $wgTitle;		
	//Allow them to edit talk pages
	if ($wgTitle->isTalkPage() && strcmp("edit", $action) == 0)
		return true;
	
	//No special cases relevant. Use established rules stored in DB.
	$this->loadFromDatabase();
	return in_array( $action , $this->mRights );
}

All the usual warnings and disclaimers about no guarantees of safety or that it'll work. Do it at your own risk. In particular; the use of the string constant "edit" seems like a horrible mistake to me, but I haven't yet found any constants that define the word for this action. Bmearns 00:13, 19 May 2006 (UTC)

(For global restrictions, this is should be done like that: $wgGroupPermissions['*' ]['editpage'] = false; and $wgGroupPermissions['*' ]['edittalk'] = true; ...but it is not implemented :( )

$wgGroupPermissions['*']['createaccount'] = false;

$wgGroupPermissions['*']['read'] = true;

$wgGroupPermissions['*']['edit'] = false;

$wgGroupPermissions['*']['talk'] = true;

works fine for me.

works for me too, except, non-logged in users still can't edit discussion pages!

works for me too, version 1.7, but I prefer this adapted hack (the right is not implicite) :

Here's the complete modified code for the function:

	function isAllowed($action='') {
		if ( $action === '' )
			// In the spirit of DWIM
			return true;
		
		$this->loadFromDatabase();

		/* Special Cases */
	        global $wgTitle;                
	        //Allow groups which have 'edittalk' right to edit talk pages --by GD
	        if ($wgTitle->isTalkPage() && strcmp("edit", $action) == 0) {
			return in_array("edittalk" , $this->mRights );
		}
		/*end special cases*/

	        return in_array( $action , $this->mRights );

	}

Then, simply, add the 'edittalk' right to the good group in LocalSettings.php :

$wgGroupPermissions['user' ]['edittalk'] = true;

In MediaWiki version 1.9.0 and above, $this->mRights will cause argument errors for in_array function. $this->mRights should be $this->getRights(). Then the full source code of the function isAllowed will be

   /* MediaWiki 1.9.0 */
   function isAllowed($action='') {
      if ( $action === '' )
              // In the spirit of DWIM
              return true;
      
      $this->loadFromDatabase();

      /* Special Cases */
      global $wgTitle;                
      //Allow groups which have 'edittalk' right to edit talk pages --by GD
      if ($wgTitle->isTalkPage() && strcmp('edit', $action) == 0) {
              return in_array('edittalk' , $this->getRights() );
      }
      /*end special cases*/

      return in_array( $action , $this->getRights() );
   }

However, $this->loadFromDatabase(); somehow changes the outcome of the in_array values ( I had problems with "bureaucrat" group not being able to change user groups). Didn't feel like investigating exactly how come, but I used the quick and dirty solution to workaround this, and it works and maybe it could help someone else also. The code:

   /* MediaWiki 1.9.0 */
   function isAllowed($action='') {
      if ( $action === '' )
              // In the spirit of DWIM
              return true;
      
      $return_value = in_array( $action , $this->getRights() );
      
      $this->loadFromDatabase();

      /* Special Cases */
      global $wgTitle;                
      //Allow groups which have 'edittalk' right to edit talk pages --by GD
      if ($wgTitle->isTalkPage() && strcmp('edit', $action) == 0) {
              return in_array('edittalk' , $this->getRights() );
      }
      /*end special cases*/

      return $return_value;
   }

Is it possible to create Group Administrators, i.e. make a user or a different group that can add and delete members of a specific group?

Is it possible to create a privilege so that only the page creator can edit their own pages within a given namespace/prevent all modifications to pages within a given namespace?

Is it possible, (using ParserFunctions, perhaps) to have a page display different content for users who are logged-in vs. those not logged-in? I'm trying to create a page for my group where Main_Page is rather bland and uninformative for those without an account, but interesting for those that are.
Solution: you don't need to touch the parser, just use CSS.
1. create a loggedin.css and a loggedout.css at the Skins/Monobook/ folder
2. loggedin.css should have #loggedout { display:none; } and loggedin.css should have #loggedout { display:none; }
3. under Monobook.php add the following before </head>, <style type="text/css">@import "$wgStylePath/logged<?php global $wgUser; if ($wgUser->isLoggedIn()) { echo('in'); } else { echo('out'); } ?>.css";</style>
4. Under the main page, enclose all anon-specific info within <div id="loggout">bla bla</div> and for registered user-specific info within <div id="loggedin">bla bla</div>
Ta-da!
- I'm not quite clear on the explanation for the CSS in the previous paragraph. I would speculate that the loggedin.css should have #loggedout { display:none; } and the loggedout.css should have #loggedin { display:none; }. Could someone clarify that for me?
One drawback is that users can still glimpse at the content by looking at the source of the website, but who would be that desperate? ;) --Yonghokim 15:43, 21 July 2006 (UTC)
- This still doesn't seem to be working --207.207.127.233 19:24, 16 August 2006 (UTC)
- There are a few mistakes in the description. Follow this modifikation and everything should work properly:
  1. CREATE loggedin.css / loggedout.css at wiki-root/Skins/Monobook/
  2. EDIT loggedin.css -> #loggedout { display:none; }
  3. EDIT loggedout.css -> #loggedin { display:none; }
  4. EDIT wiki-root/Skins/MonoBook.php before </head>: <style type="text/css">@import "<?php $this->text('stylepath') ?>/<?php $this->text('stylename') ?>/logged<?php global $wgUser; if ($wgUser->isLoggedIn()) { echo('in'); } else { echo('out'); } ?>.css";</style>
  5. EDIT Pages with: <div id="loggedout">bla bla</div> and <div id="loggedin">bla bla</div>

I want to provide a wiki in different languages and I want to create users with "steward"-rights so they can make users to sysops / bureaucrats and the other way round in all languages. The structure is the same as wikipedia's (a subdomain per language and a "commons"-wiki, every wiki can access the other's database-tables and files). How do I have to set-up the wiki for featuring stewards?

The steward/bureaucrat permission system is achieved by http://svn.wikimedia.org/svnroot/mediawiki/trunk/extensions/Makesysop/ dto 22:35, 2 September 2006 (UTC)

How exactly do we activate it?--80.177.9.87 21:25, 7 October 2006 (UTC)

Is it possible to define the inactivity timeout for users logged in?

You can define session timeouts by adding the following entry in a .htaccess file in your directory:

php_value session.gc_maxlifetime 14400

where the number is the amount of seconds before timing out.

I would like to avoid create account by anonymous logon. Is It possible?. Thanks.

User_rights#Managing_group_rights

Scenario:
- Not-logged-in-user views a page
- Not-logged-in-user clicks 'edit'
- Not-logged-in-user gets
"Login required to edit
You have to login to edit pages."
- N-l-user clicks login link
- N-l-user logins in
- Logged-in-user is at "login sucessful" page
- Logged-in-user has to navigate back to page he wants to edit

Is it possible to go from the 'click edit' step directly to the 'login form' and then directly to the proper 'edit page'?

Pointers to documentation and/or proper place to ask the question would be appreciated. Thanks!

I would like to create a "group" that has access to certain pages, and the world has no access to these pages
- I see from this page that I can assign rights to the whole wiki e.g.
- $wgGroupPermissions['user' ]['read'] = true;
- but how do I limit 'user' to some pages?
- e.g. $wgGroupPermissions['user' ]['read'] = public-pages;
- and $wgGroupPermissions['team' ]['read'] = team-pages;

Thanks! 63.162.143.21 15:07, 29 September 2006 (UTC)

Maybe you want: Preventing Access#Setting permissions for a Group on a whole new Namespace — Teratornis 21:37, 5 December 2006 (UTC)

How do you put pages into a group 'public-pages' or 'team-pages'? Thank you for helping.

Is it possible to allow the anonymous user only to create ore modiify discussionpages and avoid to edit the pages thereself? --217.7.66.69 11:14, 10 November 2006 (UTC) (Karl)

Me too, I would like to create a "group" that has access to certain pages, and the world or other groups has no access to these pages but to others

Restrict patch for Mediawiki locks all page and the user that don't have viewrestrict permission see Restrict page only. Thank you

I need to know how to prevent ANYONE besides the admin from creating a new page.

I think

$wgGroupPermissions['*' ]['createpage'] = false;

$wgGroupPermissions['user' ]['createpage'] = false;

should do the trick. --Vic-- 12 january 2007

I would like to create different groups with different rights, but where I can change these? I read the text above many times, the discribtion, but I hadn't understand it until now. Another question is: One group should become a additional right...to edit one page (for example: Article of the Week). All other shouldn't be able to edit this page. Can you help me, please?!I work with the MediaWiki Software 1.8.2

I answered my first question already. Please answer the second questions as quickly as possible. Tomsen 19:37, 5 December 2006 (UTC)

Is it possible to the user to create his own group with is own members

Is it possible to set group permissions (view, edit, delete, etc) based on categories I create in my wiki installation?

why when I remove editing permission from a created group, those in that group still can edit ?

Because permissions are additive (i.e. you grant additional rights by assigning groups, you can't revoke rights that way). A user can edit if any group he is in has edit permission. To be able to restrict editing to your custom groups, you will have to disable editing for the following (implied) groups first: "*" (all/other/anon), "user" (logged in), "autoconfirmed" (has been around a while). -- Duesentrieb 12:03, 11 March 2007 (UTC)

To answer several questions above about restricting access to a given set of pages: MediaWiki does not support that per default, but there are several extensions for more fine grained access control - see mw:Category:Page_Access_Control_Extensions; Note however that read restrictions are easy to circumvent in MediaWiki before 1.10 (and even in 1.10, loopholes remain). MediaWiki is designed to be open and accessible, not protective about sensitive data. -- Duesentrieb 11:05, 26 February 2007 (UTC)

Help:User rights

Contents

Available rights

Via extension

Tree

Changing user groups manually in the database

Managing group rights

Defaults

Questions

Navigation menu

Help:User rights

Available rights

Via extension

Tree

Changing user groups manually in the database

Managing group rights

Defaults

Questions

Navigation menu

Search