Extension talk:GroupPermissionsManager

It doesn't works at all
Hi, I've installed your extension on my MW 1.12 and set up a group named "cantread" which is not allowed to read. Then, the GroupPermission.php file is created and the line : $wgGroupPermissions['cantRead']['read'] = false; appear. But, youhou, an user in this group can read all the content of the wiki. So, I don't understand !

I've tried the same thing with the edit right and youhou can edit all pages.

Regards, --Teriblus 11:52, 16 April 2008 (UTC).
 * The way wiki permissions work is that as long as one group you belong to is allowed to do something, then you are allowed to do it. See Manual:Preventing access for some additional tips. --Skizzerz talk - contribs 22:56, 16 April 2008 (UTC)
 * As of version 3.0 of the extension, you can assign a right as "Never", which does what you want. -- Skiz zerz  23:46, 30 June 2008 (UTC)

Couple of questions
I just installed your extension on my test wiki, and so far it looks promising. I have a couple of questions:


 * I see you're using the global variable  in the initialization script.  I was under the impression that this variable had been deprecated....was this simply to have a place to store it the additional right assigned to the bureaucrat group to make the special page accessible?


 * I can see on the special page that, if a right exists (i.e., read, edit, etc.) you can modify the settings for any group with relation to that right. Have you thought about adding the functionality to add additional user rights through the MediaWiki interface, either by using a separate special page, or by adding that functionality into the existing one?

Great Looking Extensions...I can see lots of uses for this. --Hoggwild5 19:29, 23 April 2008 (UTC)
 * The wgAvailableRights call is more for me to see what rights that I have assignable in that specific extension then anything that affects the end user, I know it doesn't really do anything anymore. Also, I'm currently coding a much more powerful and user-friendly version that does allow adding new rights, etc. and modifying many groups at a time all from one page (amid many other things, like a javascript filter and the ability to only allow groups partial access to the page). --Skizzerz talk - contribs 21:32, 23 April 2008 (UTC)
 * Note to the curious: This is still in the works as version 4.x, although some of the aforementioned features may be implemented into a later version of the 3.x series. -- Skiz zerz  23:46, 30 June 2008 (UTC)

I ran into a glitch when I upgraded....
To your latest change. (I'm using MW version 1.11.2) The following line (line 52) in GPManager.body.php: $this->permissionslist = sort($this->permissionslist); causes this error message: Warning: Invalid argument supplied for foreach in .......\GPManager\GPManager_body.php on line 243 Changing line 52 back to : sort(&$this->permissionslist); seems to fix the problem. --Hoggwild5 15:08, 16 May 2008 (UTC)
 * Yeah... I didn't read the manual beforehand, so I didn't know that sort passed the input by reference and returned a boolean instead of the sorted array. Fixed in the latest version of 2.x and in 3.0 as well. -- Skiz zerz  23:46, 30 June 2008 (UTC)

Missing prefs.js
Downloaded 3.0, but believe you are missing prefs.js which is being called on line 56 of GPManager_body.php.

--Wolcott 13:31, 01 July 2008 (UTC)
 * Prefs.js is part of core, it is the javascript used on the Special:Preferences form. I didn't think I needed to replicate it since it already does the job quite well. -- Skiz zerz  17:39, 1 July 2008 (UTC)

Sorry about that. I wrote to quickly without looking at the issue. What I am getting is:

PHP Fatal error: Call to undefined method OutputPage::addScriptFile in D:\InetPub\wwwroot\wikidev\extensions\GPManager\GPManager_body.php on line 56

Looks like MW 1.12.0 does not have the function OutputPage::addScriptFile, where as 1.13alpha does. I will hack OutputPage with the new function (I hope).
 * No, I'll just switch to a supported method. -- Skiz zerz  02:14, 2 July 2008 (UTC)
 * Ok, fixed in the latest revision. Grab it from subversion (ignore the comments if you're looking at the source, I was in the middle of adding features for 3.1 when this bug report came, so I had to comment out the unfinished stuff to prevent nasty errors) -- Skiz zerz  03:04, 2 July 2008 (UTC)

Thanks for the patch. One last think, you changed the name of the file to GroupPermissionsManager.php from GPManager.php so you need to change your extension page on what to add to your LocalSettings.php.--Wolcott 08:16, 02 July 2008 (UTC)
 * Err... that wasn't me. Anyway, I'll go ahead and fix that. -- Skiz zerz  13:34, 2 July 2008 (UTC)

Warning message cleanup
Received the following message:

PHP Warning: Call-time pass-by-reference has been deprecated - argument passed by value; If you would like to pass it by reference, modify the declaration of [runtime function name]. If you would like to enable call-time pass-by-reference, you can set allow_call_time_pass_reference to true in your INI file. However, future versions may not support this any longer. in D:\InetPub\wwwroot\wikidev\extensions\GPManager\GroupPermissionsManager.php on line 173

The function call is defined as function efGPManagerExtendedPermissionsRevoke($title, $user, $action, &$result) {} and thus line 173 should be able to be changed to remove the & from in front of the variable &$result.

$res = efGPManagerExtendedPermissionsRevoke($title, $user, $action, &$result);

--Wolcott 08:23, 02 July 2008 (UTC)
 * Hm... k. I'll fix it along with the release of 3.1. -- Skiz zerz  13:27, 2 July 2008 (UTC)
 * K, 3.1 is released and all bugs that I found have been squashed, including this one. I hope it works for you. -- Skiz zerz  23:50, 2 July 2008 (UTC)

Association with Namespaces
I am not sure if I am going to ask the question correctly, but here I go.

I am about 3 months into using and setting up our wiki and each day we are expanding the requirements. We have been playing around with GroupPermissionManager for the past week and today we experimented with Lockdown and began to read up on HNP.

I really like this extension because of the GUI interface and how easy it is to use, but what do you use to associate the groups and permission you have assigned with namespaces? We are currently using namespaces to break up various areas of work assignments and our plan was to assign various groups (1 or more) to the namespaces to complete the work.

I have not exercised Lockdown extensively yet, but it seems to have what I might need except everything is defined in files on the server side (LocalSettings.php) and thus only I can access it and set it up.

I have not installed HNP yet, but atleast the information is held in a sub-page that someone other then me can edit.

So my real question is do you assign your groups to namespaces and if so do you have an extension you like.

--Wolcott 14:49 EST 03 July 2008


 * I will answer my own question by defining the following in LocalSettings.php
 * define ("NS_Test_OddAll", 1520);
 * $wgExtraNamespaces[NS_Test_OddAll] = "TstOddAll";
 * $wgNamespaceProtection[NS_Test_OddAll] = array('edit-tstoddall');


 * Then using Special:SortPermissions add edit-tstoddall permission and finally assign the permission to a group.
 * --Wolcott 16:42 EST 03 July 2008


 * A GUI method for doing something like this would be nice. Any plans for a future version of GPM? 192.73.45.37 13:55, 9 July 2008 (UTC)
 * Perhaps, depends on how hard it is to code or whether I get bored halfway through. -- Skiz zerz  14:41, 18 July 2008 (UTC)

Special:SortPermissions [Add Permission button]
After typing in a new permission and pressing the Add Permission button, nothing happens. --Wolcott 16:52 EST 03 July 2008
 * That was fixed in the latest version from Subversion (you might need to reload the page to see the change, though). -- Skiz zerz  22:43, 3 July 2008 (UTC)

Special:GroupPermissions
After manually adding a new permission in the SortPermissions.php file, because of the above issue with trying to add it in through the GUI the following notice appears when bring up the Manager Group Permission page for a group (type in a group and press GO).

PHP Notice: Undefined index: misc in D:\InetPub\wwwroot\wikidev\extensions\GPManager\GroupPermissionsManager_body.php on line 223 PHP Warning: in_array [function.in-array]: Wrong datatype for second argument in D:\InetPub\wwwroot\wikidev\extensions\GPManager\GroupPermissionsManager_body.php on line 223

--Wolcott 16:52 EST 03 July 2008


 * After debugging a little bit I found that the definition $wgGPManagerSort['misc'] = array(...); was missing from config/SortPermissions.php. When you look at the SortPermission page the 4 permission that are suppose to be in the misc group and not checked.--Wolcott 17:15 EST 03 July 2008
 * I could've sworn I fixed that bug when version 3.1 came out (since I got it too in my beta testing)... 3.2 should come out soon, so it should definitely be fixed by then. -- Skiz zerz  22:49, 3 July 2008 (UTC)
 * It's been fixed (awhile ago, actually, I just forgot to follow up over here) -- Skiz zerz  14:41, 18 July 2008 (UTC)

SortPermissions.php problem on line 40
Line 40 currently reads require_once('/config/SortPermissions.php'); but it should read require_once('config/SortPermissions.php'); The leading slash causes a file/directory not found error. Other than that, I'm liking the latest release. 192.73.45.37 13:06, 9 July 2008 (UTC)

A similar problem exists in GroupPermissionsManager_body.php on line 99. 192.73.45.37 13:19, 9 July 2008 (UTC)
 * Should be fixed. I went for absolute paths since some free webhosts resolve relative ones strangely (I've gotten a few emails on that before). -- Skiz zerz  14:41, 18 July 2008 (UTC)

Saving Sort Types and Permissions Problem
I also found another problem, but I'm not sure how to fix this one. After you add a new sort type, you must click the save button before you can assign a permission to it. If you don't, the assignment will not happen and you will have to reload the page to see the sort type. 192.73.45.37 13:12, 9 July 2008 (UTC)

After making changes to the permissions and clicking the save button, if you search for that user level again, the results of the edits, the radio buttons are not in the proper positions. I'm not sure yet if this means the permissions were not saved, but the radio buttons should reflect the current permissions of the user. 192.73.45.37 13:35, 9 July 2008 (UTC)
 * This is a pretty widespread problem, it appears. If I do a search for "sysop" or "Sysop", everything is set to false. I'm not sure if all these bugs are related, but it appears that there are some serious problems with the group permissions page and all of its functionality. 192.73.45.37 14:21, 9 July 2008 (UTC)
 * All of the above issues should be fixed now, but I don't know why it was doing that to sysop, since it should have only happened to *. Let me know if you still have issues with it. -- Skiz zerz  14:41, 18 July 2008 (UTC)

SortPermission buttons
I downloaded 3.2.2 last Friday and have installed it on my office server and home computer. I have not been able to type in a new permission name 'edit-soccer', press the "Add Permission" button and have it be added to the list. Am I missing something? JavaScript is enabled.

When the "Save" button is pressed the config/SortPermission.php file is updated, but without the new permission. Wolcott 18:11, 22 July 2008 (UTC)
 * I cannot reproduce the specific issue you are having. When I add in a permission and click "Save", the permission is added to the listing in the appropriate place alphabetically on the Special:SortPermissions page and the config/SortPermissions.php file appears to be updated correctly. The only advice I can give is make sure that you click on one of the sort types after you add the permission, otherwise the data about the new permission won't be submitted when you save and as such, no new permission will be added. However, it seems that I can't assign that permission via Special:GroupPermissions... which I'm looking into right now. -- Skiz zerz  19:48, 22 July 2008 (UTC)
 * Question 1 - When the "Add Button" is pressed what code is being executed? When I press the button the screen does not flash or updated.
 * Question 2 - To make sure I have this correct (I know it is straight forward). You should type the new permission into the Add Permission text box and press the "Add Permission" button. I assume that should ass it to the above list.  Then you should select Sort Type toggle for the new permission and press save. --Wolcott 20:00, 22 July 2008 (UTC)
 * For #1, The code at /scripts/permsort.js is being executed. It should add another row to the bottom of the large list of permissions. Please note that it does not add in duplicate permissions, so if the permission you're trying to add is already in there, it won't add it again. Also, it requires javascript, so that must be enabled on your browser. I do not plan on making it work for browsers with javascript disabled, since site admins should have js on anyway. For #2, yes, that is the procedure. You may add/change/remove as many sort types and permissions as you want before pressing save. -- Skiz zerz  20:26, 22 July 2008 (UTC)
 * OK I found one thing. I would guess that you are running on Unix/Linux server.  I am running under MW 1.12 on a Windows server.  If I look at the html source for the Special:SortPermissions page it shows  .  The addScriptFile function checks if the first character of $file begins with a "/".  If so it leaves the passed in value alone, otherwise it adds {$wgStylePath}/common/ to the front and thus we end up with the above entry in the html source.  Not sure if I am missing a setting somewhere in my LocalSettings.php file but below is the code you are using to build the file path and name:

$dir = dirname(__FILE__); $pos = strpos($dir, $wgScriptPath); $inc = substr($dir, $pos); addScriptFile("$inc/scripts/permsort.js");


 * The results for me are:

echo $wgScriptPath.nl2br("\n"); /wiki echo $dir.nl2br("\n"); C:\Program Files\Apache Software Foundation\Apache2.2\htdocs\wiki\extensions\GroupPermissionsManager echo $inc.nl2br("\n"); C:\Program Files\Apache Software Foundation\Apache2.2\htdocs\wiki\extensions\GroupPermissionsManager


 * For the time being I will hard code the $file name and see what I get. I am off to ice skating and hockey camp for the boys.  Will repost in 4 hours.--Wolcott 12:18, 23 July 2008 (UTC)


 * Two ways to fix this for all operating systems might be to remove the building of $inc and pass the whole path. $wgScriptPath which is "/wiki" can not be found in "C:\Program Files\Apache Software Foundation\Apache2.2\htdocs\wiki\extensions\GroupPermissionsManager" because Windows is "\wiki" and not "/wiki".

addScriptFile($wgScriptPath."/extensions/GroupPermissionsManager/scripts/permsort.js");
 * 1) $dir = dirname(__FILE__);
 * 2) $pos = strpos($dir, $wgScriptPath);
 * 3) $inc = substr($dir, $pos);
 * 4) addScriptFile("$inc/scripts/permsort.js");


 * or just pass permsort.js and place the javascript in /wiki/skins/common directory. The addScriptFile function will append the correct path to the file.

addScriptFile("permsort.js");
 * 1) $dir = dirname(__FILE__);
 * 2) $pos = strpos($dir, $wgScriptPath);
 * 3) $inc = substr($dir, $pos);
 * 4) addScriptFile("$inc/scripts/permsort.js");


 * --Wolcott 18:39, 23 July 2008 (UTC)


 * What browser are you using? Once I fixed the pathing issue above it worked on Safari 3.1.2, Firefox 3.0.1, but did not work on Internet Explorer 7.0.7530.13.--Wolcott 19:20, 23 July 2008 (UTC)


 * Here is a URL that discusses IE 7.0 and dynamically appending a child to a table. I am not a JSCRIPT writer but I will try some stuff tonight/tomorrow.  I search for 'jscript appendChild IE 7'.
 * Example Issue - http://bytes.com/forum/thread820895.html
 * Example Solution - http://bytes.com/forum/thread799228.html


 * --Wolcott 20:35, 23 July 2008 (UTC)


 * Here is my mod to permsort.js
 * Changed function addRow table.appendChild(tr); to table.tBodies[0].appendChild(tr);
 * --Wolcott 01:13, 24 July 2008 (UTC)

ExtendedPermissions Plugin
I am having an issue with the ExtendedPermissions plugin and a custom namespace that is protected. Either I am confused about the priority of setting permissions or the code is missing some logic. What is the reason for the ExtendedPermissions plugin? Here is my setup in the LocalSettings.php file:

define("NS_SOCCER", 5000); define("NS_SOCCER_TALK", 5001);

$wgExtraNamespaces = array(NS_SOCCER     => "Soccer",          NS_SOCCER_TALK => "Soccer_talk");

$wgContentNamespaces[] = NS_SOCCER;

$wgNamespacesWithSubpages[NS_SOCCER] = true;

$wgNamespaceProtection[NS_SOCCER] = array( 'edit-soccer' ); #Permission required to edit the namespace
 * 1) $wgGroupPermissions['sysop']['edit-soccer'] = true;       #Permission granted to users in the "sysop" group

Test Case 1 -
 * 1) Move the "ExtendedPermissions.php" file to the disabled directory (so that it is not used).
 * 2) Comment out $wgGroupPermissions so that the sysop group does not have the "edit-soccer" permission.
 * 3) Login as WikiSysop.
 * 4) Navigate to a page within the Soccer namespace
 * 5) Select the "View Source" tab (since the edit is not available).
 * 6) The source page is displayed and can't be edited or saved.

Test Case 2 -
 * 1) Leave the "ExtendedPermissions.php" file in the disabled directory (so that it is not used).
 * 2) Uncomment $wgGroupPermissions so that the sysop group has the "edit-soccer" permission.
 * 3) Login as WikiSysop.
 * 4) Navigate to a page within the Soccer namespace
 * 5) Select the "Edit" tab (since we now have the protected permission).
 * 6) The page is displayed and can be edited or saved.

Test Case 3 -
 * 1) Move the "ExtendedPermissions.php" file back into the plugins directory (so that it is used).
 * 2) Comment out $wgGroupPermissions so that the sysop group does not have the "edit-soccer" permission.
 * 3) Login as WikiSysop.
 * 4) Navigate to a page within the Soccer namespace
 * 5) Select the "View Source" tab (since the edit is not available).
 * 6) The source page is displayed and can be edited or saved. WRONG!!!

I believe that the line "} elseif( !$title->isTalkPage && $user->isAllowed('edit') ) {" in the function efGPManagerExtendedPermissionsGrant (which is the userCan hook) is not checking if the namespace is protected and has the correct edit permission.

What are your thoughts?

--Wolcott 23:00, 24 July 2008 (UTC)


 * A test for isNamespaceProtected took care of Test Case 3 above. I am not sure if the test needs to be performed in other parts of the ExtendedPermissions.php code.

if( $title->isTalkPage && $user->isAllowed('edittalk') ) { $result = true; return false; } elseif( !$title->isTalkPage && $user->isAllowed('edit') ) { if (!$title->isNamespaceProtected) { $result = true; return false; } }

--Wolcott 12:47, 25 July 2008 (UTC)