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.

--Chris 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.--Chris 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);

--Chris 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.

--Chris 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.
 * --Chris 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. --Chris 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

--Chris 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.--Chris 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)