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. Some other fail must have done that and didn't update the page. siebrand, to be exact... fucking i18n fags... they shouldn't be messing around with other people's code without permission. 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)