Manual talk:$wgGroupPermissions

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, 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)

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 18:36, 10 October 2008 (UTC)

I'd like it so that: What is the best way to go about this? Thanks Jonathan3 21:55, 13 May 2009 (UTC)
 * 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

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:

Regards Sir Lestaty discuţie 03:44, 11 October 2008 (UTC)
 * Manual:User rights
 * Manual:Preventing access
 * Manual:User rights management
 * Extension:GroupPermissionsManager

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.