Manual talk:User rights

Special:Userrights limited to only Stewards
Special:Userrights is limited to only Stewards, which includes only two users. Shouldn't that link be open to everybody?


 * Heck no. -- Sayuri 16:45, 6 October 2007 (UTC)
 * To Anonymous poster: That page serves only one purpose, to (un)assign user groups to users. If it's open to everybody, anybody could assign themselves sysop access. --Egingell 04:28, 18 October 2007 (UTC)

User rights names
Am I limited only to the names "sysop", "bot" and "bureaucrat" or can i make a new one? --Gerard armando 02:09, 20 October 2007 (UTC)


 * You can make a new one; Help:User rights gives an example of this by creating a "ninja" group. — Pathoschild 18:58:41, 20 October 2007 (UTC)

I made my own group, but when viewing it on a user's preference page it is not shown as a link, while groups like sysop or user are. Why is this?
 * Nevrmind -> Manual talk:$wgGroupPermissions

Discussion Pages
I'm setting up a wiki so that registered user cannot edit pages, but would like them to be able to use the discussion page. Is that possible? 216.226.42.234 14:41, 24 October 2007 (UTC)


 * Not currently, though it would be easy to add that feature if a developer chose to do so. — Pathoschild 06:07:29, 25 October 2007 (UTC)

Actually, I think this is possible via the $wgNamespaceProtection setting. Just add the following settings to your LocalSettings.php file:

This will only give those users who are part of the "approved" group the ability to edit the "main" namespace (but they can still edit the "talk" namespace). If you want to restrict other namespaces to editing by a single usergroup, you can add them as follows:

I would like to do something similar, but I would like it so anyone can write in discussions but only registered users can edit and add articles. I tried to configure it but it says that you need both edit and createtalk turned to true for this to happen. Does anyone know the code to make this possible?- Thanks! Steve

--216.99.65.63 15:13, 20 November 2007 (UTC)
 * If you add the following to the LocalSettings.php file:

you can restrict unregistered Users to editing discussion pages only and prevent them from editing articles. Paul2387 13:41, 10 May 2010 (UTC)

User Editing Rights for just one page
I'm setting up a wiki where registered users can only edit their own page. How do you do that?


 * You can't do that by default, though it would probably be possible to use or write an extension. — Pathoschild 04:33:21, 30 October 2007 (UTC)

Priority
I created a new user group in my wiki, let's call it "mods"·... but i want sysops to be able to manage them... i mean.. bureaucrats can edit bureaucrats, sysops and mods rights... sysops can edit sysops and mods rights, mods can only edit mods rights...

Example, protecting a page... I don't know if you get it.. how do i do it? --Gerard Armando 23:39, 8 November 2007 (UTC)

Adding Users to a Group
There is a lot of talk about editing different user groups and such, but how does one add users to a specific group?

i.e. If I wanted to add a user to group 'ninja' ? Tablanch 22:29, 18 December 2007 (UTC)


 * The first sentence states: "...which can then be assigned to (or removed from) users through the Special:Userrights interface." — Pathoschild 02:53:01, 19 December 2007 (UTC)
 * I see. Feel free to slap me. Tablanch 13:24, 19 December 2007 (UTC)

Propose move to manual
The help pages should document features for normal users, and sysops, but should not detail configuration variables. Information for server administrators belongs in the technical manual. That wasn't made clear before, but recently I've added some details to clarify the aim of the Help pages. See Project:PD help.

I know you're busy editing/maintaining this page Pathoschild. How would you feel about moving most of this. Perhaps put it on a new page "Manual:User rights"? There's also Setting user rights in MediaWiki which maybe should be merged into a manual page here.

Harry Wood 15:52, 19 December 2007 (UTC)


 * I have no objections. Maybe we can merge the Meta page to a linked subpage like "Manual:User Rights/Deprecated", for MediaWiki prior to 1.5? I think adding it directly to the same page would add quite a bit of content without being relevant to most users. — Pathoschild 18:53:49, 21 January 2008 (UTC)


 * Actually speaking of deprecated old info Help:User rights management seems to talk a lot about old MediaWiki versions. That page also needs to move/merge out of the Help namespace for the same reasons.


 * Anyway, so if that's OK, I'm going to go ahead with a move soon. Help:User rights -> Manual:User Rights


 * -- Harry Wood 19:53, 21 January 2008 (UTC)


 * Oh. I was going to go ahead with the move (and all the corrections it will require...    but actually Manual:User rights page name is 'occupied'. I thought I'd checked that, but no, there's redirect there at the moment, which a sysop user will have to delete before I can carry out the move. -- Harry Wood 14:54, 18 February 2008 (UTC)
 * Deleted. --HappyDog 16:32, 18 February 2008 (UTC)


 * Thanks. OK here goes! -- Harry Wood 17:01, 18 February 2008 (UTC)

Clickable User-Right in Special:Listusers
Hello,

when i add the Ninja-Group (as an example from the Helppage), how can i manage the group is clickable on the page Special:Listusers like Project:Bureaucrats or Project:Administrators (Sysops)? Thanks in advance kind regards TurboKanne, February, 9th, 2008.


 * See Manual talk:$wgGroupPermissions. -- Sayuri 22:43, 9 February 2008 (UTC)

The group "ninja" (for example) is still not clickable in Special:Listusers, only Bureauctrats and Administrators (behind the names) are clickable. Do you have any additional hint?
 * TurboKanne, February, 11th, 2008


 * After a couple of tests i found it only works within my wiki when i change the pages MediaWiki:Grouppage-Ninja and MediaWiki:Grouppage-ninja. Don't know why, but now it works.
 * TurboKanne, February, 15th, 2008

View source and history rights
It would be useful to have separate permissions for viewing page source and history pages. This would make it possible to prevent unregistered users from seeing anything but the current HTML version of the page, which would also have the benefit of preventing search engines and spam bots from accessing content (e.g. contact details) that have been hidden or deleted.

-- Keith Wilson 16:00, 19 March 2008 (UTC)
 * This is not the place for feature requests. Try filing a bug (severity: enhancement) on Bugzilla. —Simetrical (talk • contribs) 22:54, 19 March 2008 (UTC)

It would be enough to set a hook like $wgHooks['PageHistoryBeforeList'][] = 'checkHistoryAllowed'; and check the user's rights in a personal function checkHistoryAllowed - but even if the hook returns false or an error message, the history is still shown, because in PageHistory.php / HistoryPage.php the return value of wfRunHooks is not checked. Why is that? --DocSnyder 19:24, 12 October 2010 (UTC)

Only Confirmed mail can edit articles
Hi, i'm creating a new wiki right now. I want everybody be able to create and edit talk pages. But only users with an confirmed mail adress should be able to edit articles. (of course sysop and stuff should also be able to do that stuf....) I think if i set 'edit' to false for everybody else they can't edit talk pages, or at least i can't find a setting like 'edit_talk' or somethin. Somebody can point me to the right direction for this? --78.51.99.40 01:42, 21 April 2008 (UTC)

New user rights: what version are they for?
The following was added to the bottom of the page on June 8, 2008 :

// To hide revisions/log items from users and Sysops // For private suppression log access
 * 1) $wgGroupPermissions['suppress']['hideuser'] = true;
 * 1) $wgGroupPermissions['suppress']['suppressrevision'] = true;
 * 1) $wgGroupPermissions['suppress']['suppressionlog'] = true;

Shouldn't these user rights be added to the list, and what version of mediawiki are these user rights available for? thanks Odessaukrain 03:24, 13 July 2008 (UTC)

Permissions to be documented?
I see the following permissions on various sites. The meaning of some is obvious, but they are not documented here. Are they custom permissions?


 * boardvote
 * browsearchive
 * centralauth-admin
 * centralauth-merge
 * checkuser
 * hiderevision
 * makebot
 * makesysop
 * noratelimit
 * nuke
 * override-antispoof
 * oversight
 * renameuser
 * reupload-own
 * skipcaptcha
 * tboverride
 * torunblocked
 * uboverride

Renate 14:42, 14 July 2008 (UTC)
 * boardvote
 * browsearchive lets you do a search of deleted pages when you visit Special:Undelete
 * centralauth-admin, centralauth-merge
 * checkuser
 * hiderevision has been replaced by suppressrevision (they do the same thing)
 * makebot
 * makesysop
 * not quite sure what noratelimit does... probably has to do with the API
 * nuke
 * override-antispoof
 * oversight
 * renameuser
 * reupload-own allows you to upload new versions of images that you originally have uploaded
 * skipcaptcha
 * tboverride
 * torunblocked
 * uboverride
 * The linked ones are extension-defined and the links go to their extension pages :). I'll get around to documenting all the ones that need it later today. -- Skiz zerz  14:58, 14 July 2008 (UTC)

Creating a group
I think it'd be important to note how to create a custom group. Simply creating an entry in the array may not be straightforward to all people. And I would've never thought of initializing it using the assignment operator:

$wgGroupPermissions['mygroup'] = $wgGroupPermissions['user'];

This was necessary to deny all users from the wiki and allow specific groups. I'm just not quite sure where to fit it in the current manual page.

--Dandin1 19:32, 7 June 2009 (UTC)


 * You took the words right out of my mouth! I just posted the following on Wikimedia's Help_talk:User_rights page before I saw that the help page had been moved here:




 * I've been a wiki user for years, and a few years ago I set up and administered wikis for my department. Now I've been put in charge of running a new, public wiki. The Systems people have installed it --
 * MediaWiki 1.12.0
 * PHP 5.2.6-1+lenny3 (apache2handler)
 * MySQL 	5.0.51a-24+lenny1
 * -- and made me a bureaucrat and a sysop, and now I'm trying to come up to speed. I'm working with the MediaWiki Handbook and LocalSettings.php, but there's a lot that I can't find.


 * Right now my question is: How do I create more groups? This wiki is meant to be world-readable, but people will have to request authorization to write to it, and there are to be separate sections with separate write authorization. I thought I'd be able to do that with groups and namespaces -- group A can write to namespace A, group B to namespace B, ... -- but all I can find is
 * You can add users to these groups: bot, sysop and bureaucrat.
 * You can remove users from these groups: bot, sysop and bureaucrat.
 * I can't find word one about creating new groups, even though I see numerous groups on this wiki here.


 * Is it doable? Is there a hole in the documentation? Do I need to ask our Systems folks to do something?




 * Dandin1, it looks from your answer as if this is a Systems job. But I'd like to hear it for sure.


 * Thnidu 23:29, 24 June 2009 (UTC)

Editable talk/discussion pages
Is it possible to enable user edits only on discussion and talk pages, but not on actual articles? Or would this require a custom extension?


 * I managed to do it by patching like this :
 * includes/Title.php : add the following line at the very beginning of public function userCan and private function getUserPermissionsErrorsInternal :

if (($action == 'edit') && ($this->isTalkPage)) $action = 'edittalk';
 * includes/EditPage.php :
 * replace the following line :

if ( !$wgUser->isAllowed('edit') ) {
 * by the following :

if ( (( !$this->mTitle->isTalkPage) && ( !$wgUser->isAllowed('edit'))) || (( $this->mTitle->isTalkPage) && ( !$wgUser->isAllowed('edittalk'))) ) {
 * now you have a new right to use in LocalSettings.php : edittalk. Here is an example :

$wgGroupPermissions['*' ]['edittalk'] = true; $wgGroupPermissions['*' ]['createtalk'] = true;

move-rootuserpages... what is a root user page?
Hey all, I am a little weak on the concept of what is a 'root page'. I did a search and did not find this well explained anywhere. As a result I am unsure whether I want all users to be able to 'move-rootuserpages' or not.

Maybe a glossary section should be added to the Manual?

Action=raw
My wiki is closed to anonimous. I use external script which needs action=raw. But if I use $wgGroupPermissions['*']['read'] = false; I have no access to action=raw. How can I make such preferencies to create free rights for action=raw??? --Андрей Краснобаев 16:57, 17 December 2009 (UTC)
 * The script must be autheticated. Max Semenik 16:59, 17 December 2009 (UTC)
 * The idea is clear for me, but I'm not very skilled in php(( --Андрей Краснобаев 10:24, 19 December 2009 (UTC)
 * Then use pre-existing code. Max Semenik 10:27, 19 December 2009 (UTC)
 * Thank you for your answer! I send you the letter.--Андрей Краснобаев 11:02, 19 December 2009 (UTC)

sendemail
There seems to be a 'sendemail' right that doesn't seem documented. I would have added it to the table if I had figured out where it should have been inserted (it's obviously not editing, nor is it management). Coren 03:59, 17 July 2010 (UTC)
 * Where are you seeing this right, and what version of MediaWiki are you using? Also, are you sure that it isn't added by an extension? -- Skiz zerz  19:28, 17 July 2010 (UTC)
 * I apparently fail at searching through files. Anyway, I'd think that the 'sendemail' right would likely go under the Technical category since it kinda fits in with some of the other things. -- Skiz zerz  19:31, 17 July 2010 (UTC)

User Group rights
I have disabled all the rights for non registered users and set the white list only to the special:userlogin page. But they can still see all the pages. It doesn't seem to work.

delete pages / reupload files only without category entry
I have a problem to delete pages or reupload file if the page or file are in a category. If I delete the category entry first it is posible to delete or reupload. I have this problem as user and admn. What is wrong with my user rights? --Dirk M 20:01, 15 August 2010 (UTC)

editusercssjs
That right was split in editusercss and edituserjs in 1.16; I don't know how to properly add that to the table, though. --80.228.214.184 01:21, 6 December 2010 (UTC)

Examples : emailconfirmed
What's the difference between the following example provided on this page and the result of Manual:$wgEmailConfirmToEdit = true;?

This example will disable editing of all pages, then re-enable for users with confirmed e-mail addresses only:

-- Matsch 12:50, 23 February 2011 (UTC)

Three-tier bureaucrat system
I want to create three tiers of bureaucrats: How does one do this? I tried and failed. Leucosticte (talk) 08:10, 9 September 2012 (UTC)
 * Benefactor &mdash; can add or remove captain, lieutenant or sysop user rights
 * Captain &mdash; can add or remove lieutenant or sysop user rights
 * Lieutenant &mdash; can add or remove sysop user rights
 * I'm not sure that the = operator can be used sequentially like that. Try declaring $wgAddGroups and $wgRemoveGroups for each group separately.--Jasper Deng (talk) 04:20, 10 September 2012 (UTC)
 * Thanks; there were some other issues involved too, so I documented how to do it at Manual:Establishing a hierarchy of bureaucrats. Leucosticte (talk) 22:01, 11 September 2012 (UTC)

move-target not documented!!!!
There's no documentation about the right move-target. But if you don't set, move doesn't work.
 * Fernando Carpani (talk) 20:12, 27 May 2013 (UTC)
 * Does this have to do with moving pages in general or just moving files? Technical 13 (talk) 22:02, 28 May 2013 (UTC)

If logged in with Facebook - no need to confirm email address
If a user logs in with facebook on my site I don't want them to have to confirm their email before they edit a page. I have $wgGroupPermissions['emailconfirmed']['edit'] = true; set on my site for other regular accounts. How do I set it that users who login with facebook have their email confirmed automatically? Thanks --Tech (talk) 09:05, 9 June 2013 (UTC)


 * You'll have to have that added as a feature to whatever extension is implementing Facebook logins on your wiki. Daniel Friesen (Dantman) (talk) 09:32, 9 June 2013 (UTC)

Inherited permissions
Hello,

How do I make it so that permissions are inherited? For example, I want the user group bureaucrats to have all the rights assigned to administrators, without having to type them in again and make the localsettings file longer and harder to get my way around.

I could just add people to both groups, but I want them to be in only one group at a time.--Lyrixn (talk) 16:56, 5 August 2013 (UTC)


 * You have two reasonable options I can think of:
 * Type them in again to each group. (This is the best option IMHO and a few extra bytes isn't going to hurt anything)
 * Put the user in both groups
 * There are no other ways documented or that I am aware of to do this. Your final option might be to request that a method be added in a future version of the software on Bugzilla, and if it doesn't get closed as INVALID then eventually it could be added (but might be a long wait). Good luck! Technical 13 (talk) 17:07, 5 August 2013 (UTC)

Create new user right for edits and pages created with external links?
I think this would be an amazing help in spam prevention.

What I wanted is a way to give visitors, and non auto confirmed users to edit the wiki but not being able to post edits with external links or create pages with links unless they are autoconfirmed.

It would work something like this if you get what I mean, editlinks and createpagelinks would be new variables for edits and pages with external links.


 * I'm not sure what you're asking here. Is this a request to be implemented on a WMF wiki?  If so, I suggest filing a feature request ticket on .  If not, please be a little more clear as to what you are asking. :) Technical 13 (talk) 15:56, 8 September 2013 (UTC)
 * This is already possible using Extension:AbuseFilter, and in fact, that's pretty much what some WMF wikis use to prevent spam.--Jasper Deng (talk) 19:25, 8 September 2013 (UTC)

Permissions Frontend
I haven't yet gotten the wiki software installed, but I have to say that I am amazed that, based on this, there is apparently no admin frontend, at least not for permissions. Most forums have an admin permissions menu, so why not one of the most popular pieces of wiki software on the web? Hadashi (talk) 20:11, 19 January 2014 (UTC)
 * Special:UserRights is used for managing existing user rights. But to edit local rights I'm afraid that yes, configuration file access is needed. Rather ironically, Extension:CentralAuth does have what you are looking for, but for global groups only.--Jasper Deng (talk) 20:23, 19 January 2014 (UTC)

vipsscaler
Hi, the vipsscaler-test right is missing. Can anyone add it with the explanation of what it is used for? It would be helpful so that I can update our German help page de:Hilfe:Gruppenrechte. Thanks! XenonX3 (talk) 14:51, 2 April 2014 (UTC)

Translation of user rights description
I'd like to mark this page for translation, but it makes little sense to translate all the user rights descriptions all over again. Can we find a way to just transclude the translations with int? But then how to avoid their disappearance when a right is removed from MediaWiki, should we just paste the text here when they're removed and avoid bothering? --Nemo 22:18, 8 August 2014 (UTC)

Right precedence
The article specifies the following regarding the precedence of a right for a user with multiple groups: "If a member has multiple groups, they get the highest permission of any groups." By highest permission, does this mean that a 1/true for the right in any group trumps any 0/false for the right in any other groups? If so, this could definitely be worded better. --Tjbp (talk) 17:24, 22 August 2014 (UTC)
 * Fixed. Jackmcbarn (talk) 21:37, 23 August 2014 (UTC)

Project:OAuth administrators
The non-empty Project:OAuth administrators group is still a red link on Special:ListGroupRights. Ditto the empty Project:Account creators group. Help:User rights and Help:OAuth do not explain the  right. For comparison see m:Meta:OAuth_administrators.

Guessing, these folks decide what happens with a Special:OAuthConsumerRegistration for a listing on Special:OAuthListConsumers, and then users can connect applications, and manage their stuff on Special:OAuthManageMyGrants. This theory has a fatal flaw, I had phabricator-production [1.0] on my list, but it's not a registered application.

–Be..anyone (talk) 09:13, 26 October 2014 (UTC)