Extension talk:GroupPermissionsManager
From MediaWiki.org
Contents |
[edit] 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)
[edit] 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
$wgAvailableRightsin 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)
[edit] 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. --Skizzerz 23:46, 30 June 2008 (UTC)
[edit] 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. --Skizzerz 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).
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. --Skizzerz 13:34, 2 July 2008 (UTC)
[edit] 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)
[edit] 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
[edit] 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). --Skizzerz 22:43, 3 July 2008 (UTC)
[edit] 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
