Manual talk:User rights

Please do not post support questions here.

Instead, use one of these channels:

• Project:Support desk
• the mailing list

Further options for contacting appropriate people can be found at Communication .

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#Managing groups 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#Link to groups.3F

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:

$wgGroupPermissions['approved']['editmain'] = true;
$wgNamespaceProtection[NS_MAIN] = array( 'editmain' );

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:

$wgNamespaceProtection[NS_USER] = array( 'editmain' );
$wgNamespaceProtection[NS_IMAGE] = array( 'editmain' );
// Etc...

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:

$wgGroupPermissions['*']['edit-main'] = false;
$wgGroupPermissions['*']['edit-talk'] = true;
$wgGroupPermissions['user']['edit-main'] = true;
$wgGroupPermissions['user']['edit-talk'] = true;
$wgNamespaceProtection[NS_MAIN] = array( 'editmain' );
$wgNamespaceProtection[NS_USER] = array( 'editmain' );
$wgNamespaceProtection[NS_MEDIAWIKI] = array( 'editmain' );
$wgNamespaceProtection[NS_<WIKI-NAME>] = array( 'editmain' );
$wgNamespaceProtection[NS_HELP] = array( 'editmain' );
// plus any other namespaces you may have

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#Target readership - Normal users.

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 meta: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#Link to groups?. --Sayuri 22:43, 9 February 2008 (UTC)

Thanks for this hint, but unfortunately this does not resolve my issue. 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 [1]:

#$wgGroupPermissions['suppress']['hideuser'] = true;
// To hide revisions/log items from users and Sysops
#$wgGroupPermissions['suppress']['suppressrevision'] = true;
// For private suppression log access
#$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. --Skizzerz 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;

• This seemed to only create a 500 error. Is this dependent on a specific mediawiki version?

• This solution, does not seem to work. Anon user is able to edit and create all pages, not only talkpages.

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?

Same comment here, I didn't got an answer to my question what a 'root user page' is and where (and why) a general user should 'move' it. Wasn't able to find an answer elsewhere. The definition of root which is applicable here is "the first or top-most directory in a hierarchy", isn't it? Root_(disambiguation) (Wikipedia.org) So why should a user be allowed move the top-most directory of his user page? I think giving an answer in this article to this with a glossary would be very helpful --LenaKö (talk) 14:27, 4 July 2017 (UTC)

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? --Skizzerz 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. --Skizzerz 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)

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:

# 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;

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

Three-tier bureaucrat system

I want to create three tiers of bureaucrats:

• Benefactor — can add or remove captain, lieutenant or sysop user rights
• Captain — can add or remove lieutenant or sysop user rights
• Lieutenant — can add or remove sysop user rights

How does one do this? I tried and failed. Leucosticte (talk) 08:10, 9 September 2012 (UTC)

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:
  1. Type them in again to each group. (This is the best option IMHO and a few extra bytes isn't going to hurt anything)
  2. 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.

$wgGroupPermissions['*']['edit'] = true;
$wgGroupPermissions['*']['editlinks'] = false;
$wgGroupPermissions['*']['createpage'] = true;
$wgGroupPermissions['*']['createpagelinks'] = false;


$wgGroupPermissions['autoconfirmed']['edit'] = true;
$wgGroupPermissions['autoconfirmed']['editlinks'] = true;
$wgGroupPermissions['autoconfirmed']['createpage'] = true;
$wgGroupPermissions['autoconfirmed']['createpagelinks'] = true;

• 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 Bugzilla:. 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)

This is a right, which is added by an extension (by the Extension:VipsScaler). There are plenty of extensions, which bring their own rights and none of them have been added to this page, also as this would result in a never-ending, always out of date list. Instead of listing all custom, third-party rights, I think it's better to only list those rights, which come with the MediaWiki Core and only to show, how custom rights can in theory read as: in the source code) be given. --88.130.120.5 14:37, 23 November 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 mwoauthmanageconsumer 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)

Meanwhile Project:OAuth administrators exists (again) here, it's now a soft redirect to the corresponding Meta user group rights page. And the theory was fine, but stupid user missed that the 20 registered "connected apps" on the first page are not all registered connected apps. –Be..anyone (talk) 09:12, 3 January 2015 (UTC)

Help

Hi, I want that the bureaucrat's group will inclunde the all sysops' permissions. How can I do that> thanks for helpers Dekel E (talk) 16:00, 31 December 2014 (UTC)

$wgGroupPermissions['bureaucrat'] = array_merge($wgGroupPermissions['sysop'], $wgGroupPermissions['bureaucrat']);

. In the future, though, please direct help inquiries to Project:Support desk. Thank you.--Jasper Deng (talk) 09:26, 1 January 2015 (UTC)

Default Value for Rights

Is the default value for rights not defined/assigned to a group in either DefaultSettings.php or LocalSettings.php set to false? It seems to be implied, but I couldn't find confirmation of that on the Manual:User_rights page. — Preceding unsigned comment added by 204.209.209.130 (talk • contribs)

Are you talking about Manual:User_rights#Default_rights, and did you miss that, or is something wrong with it? –Be..anyone (talk) 07:06, 15 March 2015 (UTC)

Yes, I'm talking about Manual:User_rights. For example, if suppressredirect was not defined in DefaultSettings.php, would the value be false? This isn't actually explicitly stated on the page. — Preceding unsigned comment added by 204.209.209.130 (talk • contribs)

Sorry, I don't know, but the folks on the support desk can help, unlike me they have actually installed MediaWiki. –Be..anyone (talk) 17:59, 16 March 2015 (UTC)

By default, if a right does not exist, then the acccording array kay is not set and this key won't have a value. So if in PHP you check for that array key, the result will be that it is not there or if you check its value, then it will not be false, but PHP will evaluate it to false.

Sidenote: Possible values for user rights only are true and false. In the case of a non-existing right/array key, its value will definitely not be true. Checking, if it is false however will not only cover cases, where the right has been set to false, but also cases, where the right does not exist at all - and getting the same result both times might not be what you want. So better check, if the right is granted/if the value is true: If you want to know, if a right is set, it will be save to explicitly see, if it is true. --87.123.29.48 17:59, 3 February 2016 (UTC)

New right to allow read/write in custom namespace

I am developing my own wiki and I would like administrators to be able to view and edit in the Admin and Admin talk namespaces. I know it's possible somehow, but probably very difficult. Any help? Some unimportant person (talk) 12:32, 17 May 2015 (UTC)

In Mediawiki edit rights (for a group) can be handled very well for each NS but you can not grant read rights on a specific NS. If you have a private Wiki then all users (logged in) can read every page on the Wiki, except some special pages. What you want is a Access Control List.

Some stuff to read:

• Category:Page specific user rights extensions
• Security issues with authorization extensions
• Manual:$wgNamespaceProtection
• Manual:Image Authorization
• Manual:User rights
• Manual:Preventing access

If you really want to be able to specify read rights on NS or pages you are probably better of with Wiki software that has a Access Control List by default, like TikiWiki. --Felipe (talk) 05:33, 18 May 2015 (UTC)

Possible Error In Ninja vs Writer Examples

I'm probably missing some finer points, but I guess it is the job of us newbies to suggest clearer documentation.

I wish there was more description for the purpose of the MidiaWiki:Group-<group-name> Pages. Where and when are their contents used? The examples given are slightly confusing because the Ninja example has a <group-name>='ninja' and Group page contents of:

• Ninjas
• ninja
• Project:Ninjas

while the Write example lists <group-name>='Write', and has Group page content of:

• Writers
• Writer
• Project:Write

There seems to be a contradiction here. If one example was plural then why not the other? Should the writer example actually be

• MediaWiki:Group-Write (content: Writers)
• MediaWiki:Group-Write-member (content: Write)
• MediaWiki:Grouppage-Write (content: Project:Writers)

WmBliss (talk) 23:17, 30 August 2015 (UTC)

Proxy edit request for an anon

Hi there. I would like to request an edit to this page, as semi-protection is applied and I don't have an account on here.

Within the wikitable in the "List of permissions" section is an entry for the unblockself permission. The current description says...

"Unblock oneself Without it an administrator that has the capability to block cannot unblock themselves if blocked by another administrator"

...which is missing some punctuation. It should be:

"Unblock oneself. Without it, an administrator that has the capability to block cannot unblock themselves if blocked by another administrator"

Minor edit. Easy to fix! 96.48.248.2 06:18, 6 June 2016 (UTC)

I'm not sure how to get to the "Unblock oneself." part, but the following sentence I attempted to update that. Tropicalkitty (talk) 15:15, 6 June 2016 (UTC)

Saw your edits - didn't realize there was a lot of advanced syntax within the table, heh. Much appreciated though! 96.48.248.2 19:23, 6 June 2016 (UTC)

Giving a User rights without Group Permissions

It is possible to explicitly specify a username rights e.g. reading-rights for User "Patrick"?

Ambiguous numbers

The Description of the delete right reads:

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

This would be clearer if the numbers were identified as versions, and the text had better punctuation, e.g. thus:

Delete pages. In versions 1.5–1.11: allows the deletion or undeletion of pages. In versions 1.12+: allows the deletion of pages; for undeletions, there is now a separate undelete right, see below.

Yahya Abdal-Aziz (talk) 15:02, 30 January 2018 (UTC)

Error in page: Mediawiki prefix

I'm fairly sure that every time it suggests creating a page with a Mediawiki: prefix, it really means <YourWiki>:. Example: MediaWiki:Group-<group-name> Calion (talk) 00:45, 17 February 2018 (UTC)

I assume by <YourWiki>: you mean the Project: namespace (if not, please correct me). In that case, the text means exactly what it says: to create the pages in the MediaWiki: namespace. I'm guessing your confusion arises from the fact that this is the MediaWiki wiki, so you would expect the Project namespace here to use "MediaWiki" as an alias, but in actuality it has no alias, and instead just uses "Project" (as you can see from the output of {{ns:4}}: Project).

「ディノ奴千？！」^{? · ☎ Dinoguy1000}

05:32, 17 February 2018 (UTC)

Yes, thanks. I see that that's right. Calion (talk) 19:09, 17 February 2018 (UTC)

not allowing to view the Common.css

I want to disable viewing of Common.css for visitors and registered users so that only the sysops can see and edit the .css Page. Can someone help me?

It's not possible with the standard MediaWiki software (see Manual:Preventing access#Restrict viewing of certain specific pages). It may be possible with an extension, but as documented on that page, any extension offering that ability isn't necessarily reliable. In any event, if someone really wants to see Common.css, all they have to do is use the developer tools in the browser, so hiding it would only prevent seeing it for people who don't know how to use those tools. – Robin Hood  ^(talk) 18:55, 20 February 2018 (UTC)

Preventing visitors from certain pages

Hi

I am looking at making it so only users who are logged in can view a Draft: namespace. People who are not logged in won't be able to view the contents of this namespace.

Is this possible? If so, how would I be able to implement it?

Any help is appreciated.

Gary

--Squeak24 (talk) 15:51, 22 October 2018 (UTC)

You'll need to use Extension:Lockdown --Ciencia Al Poder (talk) 09:33, 23 October 2018 (UTC)

Give sysops all rights except bot rights

# Give sysops all rights except bot rights
foreach ( $wgGroupPermissions as $group => $groupPermission ) {
	if ( $group != 'bot' ) {
		foreach ( $groupPermission as $specificPermission => $value ) {
			if ( !isset( $wgGroupPermissions['sysop'][$specificPermission] ) ) {
				$wgGroupPermissions['sysop'][$specificPermission] = true;
			}
		}
	}
}

Setian~mw (talk) 23:15, 22 February 2019 (UTC)

MediaWiki pages to create with new group

The page says one should generate pages [[MediaWiki:Group-<group-name>]], [[MediaWiki:Group-<group-name>-member]], [[MediaWiki:Grouppage-<group-name>]] "with fitting content". What are those pages and what would be fitting content? I tried to find an example on this wiki, e.g. [MediaWiki:Group-Account creators]], and it is a red link. Tenbergen (talk) 20:44, 30 January 2022 (UTC)

That's because the actual pages are MediaWiki:Group-accountcreator and MediaWiki:Group-accountcreator-member. They need to contain the displayed name for the group (in this case, "Account creators") and a group member (in this case "account creator"). KockaAdmiralac (talk) 20:47, 30 January 2022 (UTC)

No Edit right for SysOp?

More than half the rights granted-by-default to sysop say "- requires the edit right", but the default rights listed for sysop don't include the edit right.

As my site's sysop, I definitely have the ability to edit all the things (as far as I can tell). I'm just wondering if sysop is missing from the User groups that have this right by default column & edit is missing from the Default rights column...

...Or does sysop actually lack the edit right? (Perhaps because all sysops are also users and users already have the edit right?) In which case, if I revoke the edit right for users, do I need to then explicitly grant it for sysops to remain fully functional?

Thanks for your time and I pre-emptively request forgiveness for my dumba$$ery. Medicinestorm (talk) 20:04, 7 April 2023 (UTC)

Administrators (sysop) don't need to have the (edit) right if All Users (*) and Registered Users (user) already have it. Since all usergroups automatically have every permission that All Users and Registered Users have. However I do feel that it wouldn't be too far fetched if Administrators were granted the (edit) right by default in a later version of MediaWiki. Just in case there are any bugs preventing users from automatically receiving permissions from any implicit usergroups they are part of. But yes, if you were to revoke the (edit) right from All Users and Registered Users, then Administrators would no longer be able to use the (edit) right. ― C.Syde (talk | contribs) 01:03, 8 April 2023 (UTC)

That makes sense. Thank you very much. Medicinestorm (talk) 20:38, 9 April 2023 (UTC)

No problem! :) ― C.Syde (talk | contribs) 23:45, 9 April 2023 (UTC)