Manual talk:$wgGroupPermissions

How to allow only sysop user to edit pages

How to allow only sysop user to edit pages (version 1.5) ?

I tried the following :

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

but it has no effect. What is the correct configuration to allow only sysop to edit pages ?

Try adding

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

between the two lines you aready tried. 158.135.133.13 19:03, 26 April 2006 (UTC)

If you restricted access for everybody in the first line, that´s all, because sysop still can edit

Is there a way to set group permissions for a wiki to disallow anonymous and user editing, but enable it for a few pages? Of course I know how to (and already do) disable, but I don't know how to set individual pages edit-able. The number of edit-able pages are outnumbered by protected pages in my wiki, if that makes any sense, heh. 24.21.71.180 13:09, 4 August 2006 (UTC)

Recent edit

someone just changed

"false" to "true" in the example's first line

this is incorrect, isn't it (i just tried it and it opened up the site for anonymous editing)

is there a reason it was changed?

--haleden

no response, so i reverted the edit

An anonymouse user - possibly someone trying out wiki, possibly a deliberate vandal, possibly just someone who was confused. Either way the original version was the correct one, so thanks for the revert. --HappyDog 04:09, 13 November 2006 (UTC)

Default values

Default value is an array, but an array of false values or true? I suspect the former. Either way, the documentation could perhaps be improved. --Kingboyk 18:37, 18 November 2006 (UTC)

The standard method is to hit the 'edit' button, make the improvement, click save. --HappyDog 00:56, 23 November 2006 (UTC)

Autoconfirmed and Emailconfirmed rights

In the manual it says that the usergroup 'autoconfirmed' are users with the 'autoconfirmed' permission. Same goes for the 'emailconfirmed' group. This can also to be seen in the DefaultSettings.php file. It is not clear to me what the 'autoconfirmed' and 'emailconfirmed' permissions (not group) do. What is their purpose in MediaWiki (1.9)? Where is it used? Can someone explain that to me, cus at the moment I don't understand the meaning of the two rights (again not the groups). It is not explained in the manual page.
--NicoleBekkers 12:07, 26 February 2007 (UTC)

Autoconfirmed is assigned to users automatically by MediaWiki; you can set the time and number of edits after which this happens. e.g.

$wgAutoConfirmAge = 3600; // User must exist for 1 hour
$wgAutoConfirmCount = 5;  // User must have made 5 edits

If you do this, you can then set up RC patrolling so new users are patrolled before both of these conditions are satisfied. So:

$wgGroupPermissions['user']['autopatrol'] = false;         // New users are patrolled
$wgGroupPermissions['autoconfirmed']['autopatrol'] = true; // Established users aren't

Autoconfirmed is also the semi-protect level on pages - "Block unregistered users" actually requires the Autoconfirmed permission.

Emailconfirmed means the user has registered their email address with the wiki and it was successfully confirmed. It does nothing unless email functions are turned on. --83.104.41.175 14:05, 13 May 2007 (UTC)

Is there an "anonymous" group for page by page restriction?

I found :

* = All users (incl. anonymous)

According to the tests made on my wiki, I corrected the manual into:

* = Anonymous. 

Previously, the page was wrong. Looking in the history of the page ( [1]), I found that I was right. The true meaning of "*" is "anonymous group"

I also look for something such :

$wgGroupPermissions['anonymous']['read']['Page_with_really_interesting_data'] = false;

please answer on my talk page too. Yug 01:07, 11 March 2007 (UTC)

You can create a namespace which you set to ['user']['read']. There is no page by page restriction. You may look into Category:Page_Access_Control_Extensions. Or make your own changes, look at page table page restriction. --GunterS 01:20, 11 March 2007 (UTC)

Link to groups?

On Wikimedia wikis, I notice that the links to STEWARD etc. are linked like Sysop and Bureaucrat. Is this a system message, database entry or some setting I've yet to find? --83.104.41.175 13:46, 12 May 2007 (UTC)

It's a system message. For example, if you want to link the developer group to the page project:developers, you would create MediaWiki:Grouppage-developer and put Project:Developers as its contents. This has been tested on MediaWiki 1.11 and it works on that version. --Sayuri 05:12, 4 July 2007 (UTC)

talk rights ?

I just created a wiki with no edit rights for normal users, but i'd like to allow authenticated users to use the talk pages. I set this

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

to disallow the edit functions to all, and put that

$wgGroupPermissions['user']['move']            = false;
$wgGroupPermissions['user']['read']            = true;
$wgGroupPermissions['user']['edit']            = false;
$wgGroupPermissions['user']['createpage']      = false;
$wgGroupPermissions['user']['createtalk']      = true;
$wgGroupPermissions['user']['upload']          = false;
$wgGroupPermissions['user']['reupload']        = false;
$wgGroupPermissions['user']['reupload-shared'] = false;
$wgGroupPermissions['user']['minoredit']       = false;
$wgGroupPermissions['user']['purge']           = false;

to allow edition of discussion.

it works ok to don't edit pages, but the normal users cannot discuss though i set the createtalk to true

Did i miss anything on the settings ? --V.chosson 14:55, 31 May 2007 (UTC)

EditTalk, perhaps? 98.202.56.80 11:24, 15 February 2008 (UTC)

I tried edittalk, doesn't work, tried talkedit, that doesnt work, apparently if edit is false there is no way to edit any page including the talk pages... maybe restricting the namespace works? - nouse4anick

I had the same problem. I use the following solution : I protect every page, and then allow * to edit but not to create pages. --Serenity 21:03, 23 May 2009 (UTC)

I'm trying to do the exact same thing.. I've even gone as far as creating a 'trusted' group that has all of the default permissions that the user group gets so I could experiment with the user group's permissions. The 'trusted' users can now edit pages as well as talk/discussion pages, and 'users' cannot edit anything, including their own talk pages. My goal is to allow the 'trusted' users to manage unprotected content, and only allow 'users' to edit talk & discussion pages. Himbeau 21:15, 29 March 2010 (UTC)

I have a thread opened here: mwusers

Solution

Found this great article by hoggwild, from the mwusers page linked above.

     The first link above led me to an "unsafe" page. I'd recommend clicking with care. -Yanni

Synopsis: Add the following to LocalSettings.php

# This section disables reading except for registered users (This may not be something that you want)
$wgGroupPermissions['*']['read'] = false;  // Disallow anonymous users from reading articles
$wgGroupPermissions['user']['read'] = true;  // Allow users to read articles

# Establish namespace protection for all but discussion and user pages
$wgNamespaceProtection[NS_MAIN] =
$wgNamespaceProtection[NS_USER] =
$wgNamespaceProtection[NS_PROJECT] =
$wgNamespaceProtection[NS_FILE] =
$wgNamespaceProtection[NS_IMAGE] =
$wgNamespaceProtection[NS_TEMPLATE] =
$wgNamespaceProtection[NS_HELP] =
$wgNamespaceProtection[NS_CATEGORY] = array('editarticles');

# This section allows users to edit only discussion and user pages, allows sysop to edit everything, 
# and everyone else no editing
$wgGroupPermissions['*']['edit'] = false;  // Disallow anonymous users from editing any articles
$wgGroupPermissions['user']['edit'] = true;  // Allow users to edit non-protected articles
$wgGroupPermissions['sysop']['edit'] = true;  // Allow sysop to edit non-protected articles
$wgGroupPermissions['sysop']['editarticles'] = true;  // Allow sysop to edit protected articles

Worked like a charm for me in v 1.16. - jcoreil

purge ??

Hi all Thanks for the good job already done ! But there is no description of the purge command ! I think this is to purge the "historique", but it should be written Thanks, Matt

image auth?

from Manual:Image authorisation -- what perms relate to the ability to see uploaded files? Sj 14:30, 14 July 2007 (UTC)

Restrict the use of HTML

I want to restrict the use of HTML ($wgRawHtml is true) for users and anonymous. How could I do it? EmuAGR 08:45, 3 September 2007 (UTC)

Allow just registered users to edit pages?

what do i need to configure to allow just registered useres to edit pages AND the user shall just get the registration after confirmation/approvement by SYSOP.--82.113.113.81 08:58, 27 September 2007 (UTC)

See Help:User rights. —Pathoschild 00:43:44, 28 September 2007 (UTC)

I've tried this, but haven't gotten it to work. As soon as I add $wgGroupPermissions['*']['edit'] = false; I can Page Cannot be Displayed. I don't care if anonymous users view pages, but I would like to (be able) to restrict edit to registered users. ~sb1920alk 13:09 5 June 2008 (CDT)

Update: I still can't get this to work the correct way. As soon as I add any group permission setting to localsettings (even copying and pasting what's already in defaultsettings and not changing it), none of the pages will load. I had to resort to editing Default Settings. I'm aware this change will be overwritten when I upgrade, but it works correctly for now. ~sb1920alk 11:00 20 June 2008 (CDT)

Have you found a solution to this problem? I want my unregistered users to be able to discuss pages, but not edit them. There should have been an edittalk parameter as well. /Jesper --85.89.79.106 12:02, 3 July 2008 (UTC)

The GroupPermissionsManager extension has got the edittalk parameter, but it's not working the way it's suppose to.. An anonymous visitor can enter the Talk page, but when he/she hits Save, it says you must login for saving it... Well, need to look closer at this problem... /Jesper --85.89.79.106 12:28, 3 July 2008 (UTC)

Has there been any update on this? I have exactly the same problem (wanting to let anyone edit talk pages, only reg. users edit all pages) ?? 82.21.98.102 11:30, 10 October 2008 (UTC)

GroupPermissionsManager should work. If not, there's the Talkright extension. —Emufarmers^(T|C) 18:36, 10 October 2008 (UTC)

I'd like it so that:

1. anonymous users can only view pages
2. registered users can edit talk pages (only)
3. a subset of registered users (chosen by admin) can edit all pages

What is the best way to go about this? Thanks Jonathan3 21:55, 13 May 2009 (UTC)

Try the following so that anonymous users can only view pages

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

Then so that only registered users only can edit all pages and a subset of registered users can that were chosen by admin do this

$myProtectNamespaces = array(NS_MAIN, NS_CATEGORY, NS_USER, NS_PROJECT, NS_SPECIAL, NS_TEMPLATE, NS_HELP, NS_MEDIAWIKI);
foreach($myProtectNamespaces as $ns){
    $wgNamespaceProtection[$ns] = array('thenameofyourspecialusergroup'); // the select group of users that would be allowed to edit
}
$wgGroupPermissions['thenameofyourspecialusergroup']['thenameofyourspecialusergroup'] = true;
$wgGroupPermissions['thenameofyourspecialusergroup']['edit'] = true;
$wgGroupPermissions['thenameofyourspecialusergroup']['read'] = true;
$wgGroupPermissions['thenameofyourspecialusergroup']['delete'] = true;

#lastly make the sysops(Administrator) group capable of adding users to that group
$wgAddGroups['sysops'] = array('thenameofyourspecialusergroup');

--Machaiol 22:14, 29 April 2010 (UTC)

Just tried the code above and it works great, except that I had to remove NS_SPECIAL from the list or accounts couldn't be created by people not already in the special group. Thanks, I never would have come up with this on my own -- David

New Groups

This may sound stupid but I'm new to the whole wiki thing and I am trying to develop my own wiki for school usage. I was wondering if it was possible to create new groups with their own privlages? I want to create different groups for each member of my student government and their assigned tasks so they can have full control over their pages... Is that possible or would I just have to regulate who does what on which page. And how what can I do to make it so that if one does not have a username and password, they can only see the main page... i would prefer a way for them to not be able to view ANY pages without being a logged in user... what can I do for this? THANKS...

Of course this is possible, please read:

• Manual:User rights
• Manual:Preventing access
• Manual:User rights management
• Extension:GroupPermissionsManager

Regards Sir Lestaty ^discuţie 03:44, 11 October 2008 (UTC)

Help $wgGroupPermissions is not working and being ignored

My wiki went under spam attack and I've been trying to lock it down. It seemed no matter where i put the $wgGroupPermissions line, it was ignored. I have figured it out. For whatever reason, the first place I grabbed the code had funny single quotes in it. The kind that angle like this: ‘’. If your pages are still editable for anonymous users after you have added the line:

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

Then check that the quotes are indeed simple single quotes.

For those of us who need to stop the spam from ruining too many pages in a hurry, this is a good first step before implementing other ideas discussed here.

Export right

is there a Export right that is define ?

Are users able to export if they're not able to read ?

Thanks, --almaghi 13:45, 11 June 2009 (UTC)

There is no export right, but users can't access Special:Export without the read right (unless it's whitelisted, of course). —Emufarmers^(T|C) 17:31, 11 June 2009 (UTC)

11:20, 18 January 2018 (UTC) 195.234.58.40: this could solve "Export right"

#in Localsettings.php
$wgGroupPermissions['sysop']['export'] = true;
function removeExportSpecial(&$aSpecialPages)
{
global $wgUser;
  if ( !$wgUser->isAllowed( 'export' ) ) {
        unset($aSpecialPages['Export']);
        return true;
  }
}
$wgHooks['SpecialPage_initList'][] = 'removeExportSpecial';

How to disable view source tab for anonymous users in mediawiki 1.20

How to disable view source tab for anonymous users in mediawiki 1.20? The 'view source" tab should be visible but it should be disabled from anonymous users. How to do that?? please reply ASAP.I am new to mediawiki.Can you give me precisely what code and in which file i have to put so that view source tab is disabled for anonymous(non-logged in) users?

Emailconfirmed users not able to edit pages

I am using Mediawiki 1.20 I gave settings $wgGroupPermissions['emailconfirmed']['edit'] = true; Still users whose email addresses are getting confirmed through confirmation mail and code are not able to edit wiki pages. Please reply ASAP--Sanjeetkumarit (talk) 09:46, 15 October 2014 (UTC)

Unable to give autoconfirmed skipcaptcha right

I recently tried manipulating some parts of my LocalSettings to make it so autoconfirmed users (which now have a requirement above 0 seconds of life and 0 edits), would be able to bypass CAPTCHAs. The lines I added are as follows:

$wgAutoConfirmAge = 86400;
$wgAutoConfirmCount = 10;
$wgGroupPermissions['autoconfirmed']['skipcaptcha'] = true;

However, when I go into Special:ListGroupRights, the Autoconfirmed group does not seem to have this right. Oddly enough, when I misspelled "skipcaptcha", the (useless) right was listed as being usable by Autoconfirmed users. However, when I fixed my typo, the entire right is not there. Schiffy (talk) 19:00, 16 October 2014 (UTC)

Functionality to make specific pages inaccessible has not been extensively tested for security

What does this phase mean exactly in this article? What connection is between creating user groups and this? Арскригициониец (talk) 23:03, 20 November 2020 (UTC)

Création de compte utilisateur non enregistré

Je souhaite qu'un utilisateur anonyme puisse créer un compte mais il ne doit pas pouvoir lire le wiki avant (ou juste la page d'accueil sans lien vers le reste). lorsque j'utilise $wgGroupPermissions['*']['read'] = false; je n'accède pas à la page de création de compte, lorsque je met la condition à true j'accède à la page de création mais également à l'ensemble des pages

Existe t'il une solution? merci Schub srx (talk) 14:28, 12 November 2022 (UTC)

extension.json?

I´m a bit confused - did I understand that right?

Since REL 1.25 the configuration via variables in LocalSettings.php is deprecated and an "extension.json" - file should be used instead.

According to Manual:Extension registration the location of the "extension.json" should be specified as an addititonal Parameter for wfLoadExtension. But the wgGroupPermissions-Settings seems to be Extension-independent.

Has someone ever tried to set the permissions via "extension.json"?

Do I just have to create a file with that name in the installation-directory without an additional reference in LocalSettings.php?

This would mean that there can be just a single "extension.json" - containing the settings for all extensions.

Or is it possible to have multiple extension.json - files (LDAPProvider.json, LDAPAuthentication2.json, etc.)?

Or do I have to change the "extension.json" under the entensions-folder (e.g. /extensions/LDAPAuthentication2/extension.json)? UweAtwork (talk) 11:57, 1 June 2023 (UTC)

I was wondering the same thing. From a quick review of the commit it looks like the change referenced was how extensions are registered with Mediawikie (it introduced using wfExtension("Some Extension"); in LocalSettings.php along with requiring an extension.json file to provide info about the extension. I'm wondering if there's a bit of a mixup with information, i.e. extension.json is used if you want an extension to control group permissions, but LocalSettings.php is still used if you are updating these without an extension.

FWIW, the LocalSettings.php method still seems to be working for me in MW v1.41.0. Coyotefather (talk) 17:40, 7 January 2024 (UTC)

This page is completely misleading. If you are a wiki operator attempting to change group rights, you can (and must) still use $wgGroupPermissions. Any mention regarding extension.json is solely for developers developing extensions. —Mainframe98 _talk 20:09, 7 January 2024 (UTC)