Extension talk:UserRightsList

Security notice - users should upgrade to 0.4 from any previous versions
A vulnerability was pointed out that could lead to injection of permissions changes. This could lead a malicious user to elevate his own status, allowing all kinds of nasty things. --JimHu 00:37, 17 May 2008 (UTC)

Not getting watchlist emails
Note that for reasons I don't understand, I don't get emails from this wiki when these pages are updated, even though they're on my watchlist. I do seem to get emails notifying me that my User talk page has been modified. --JimHu 22:58, 25 May 2008 (UTC)

Hooks
Remember for MediaWiki 1.11, all your hooks need to return true or false.
 * thanks for the catch. I know I missed a return true at the end of loadmessages, did you see any others?  I just added that to the example at Writing_a_new_special_page so others won't do what I did and miss it.
 * -- JimHu 15:22, 20 August 2007 (UTC)


 * Yeah, line 275:  should return true as well.
 * fixed in 0.21

Minor bug
This extension fails to take into account $wgDBprefix so far. :) I've put up a quick patch here; I tested it briefly, but I can't guarantee that I didn't miss any places where it should be added as well. -- Schneelocke 20:37, 28 August 2007 (UTC)

This patch indeed helps. Thank you. 89.179.245.37 17:23, 2 September 2007 (UTC)
 * fixed in 0.21
 * Looks like it's broken in the same way with respect to $wgDBprefix in 0.22. Jlerner 23:53, 2 March 2008 (UTC)

Slight hack
Hi, thanks for a great extension, it helps us maintain our users really well on out site. The only problem we faced was that we have users log in with an ID - via LDAP, and the user id as printed out in the Rights List isn't meaningful. So, we set a site policy where users have to go to their preferences to fill in their Full Name at least, then I altered two small sections of code. The firs was to add u.user_real_name to the SQL select statements, and then of course I extended the output into the first fields  to print out the real name, works a treat, we can now see a proper name against a number. Thanks again, Nibb 19:42, 20 September 2007 (UTC)

Proposal for better readability
Hi,

seems like a nice extension to me, but I'm having trouble staying in the correct line for a user. Would it be possible to enhance usability through shading every other line of the grid in a slightly darker colour? I know this "reading-help" from Thunderbird and it really makes a difference.

--Katwol 11:40, 13 December 2007 (UTC)
 * done in 0.22

Kind of bug
Hi, I was previously using UserRightsList extension version 0.1 and found it very useful. Today I upgraded to 0.22 and I found that it is not possible to remove users from all groups. At the moment, user has to be a member of at least one group (any group). When I uncheck last remaining group for a user, only SELECT queries are executed in DB. :-(

I use MediaWiki 1.11.1

Could it be fixed, please?

Thanks, Pawel

Some changes don't stick when using filter
When I use the "registered after" filter, it seems that changes don't stick to certain users - those who appear in the second group of 50 or higher when not using any filters. Anyone experience something similar? Jlerner 00:20, 3 March 2008 (UTC)

Does not delete
help:: I install the extension in my Wiki (V1.10). I have two avail access [bot and Sysop). If I add a user to one of the group save and enter it works . However it will not save any addition update or delete for the users. So if I tried to remove the user access .. it allow me to uncheck and then it redirect me to the user list... no errors but does not change the user access.

Database Syntax Error
When I try to run this extension, I got the following error:

A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was:

(SQL query hidden)

from within function "". MySQL returned error "1142: SELECT command denied to user 'blogger'@'localhost' for table 'user' (localhost)".

At first, I thought it was a permissions error, but the user has all privileges for that database. This really looks like something I'd love to have. Any ideas what's going on here? Anyone experienced this before? --StochasticJack 19:20, 2 April 2008 (UTC)


 * I get the same error message and really need to get this extension to work. Has anyone got any ideas?
 * --Adam 12:15, 25 April 2008


 * 0.3 just released. Please try it; I hope it fixes the problems. --JimHu 21:45, 15 May 2008 (UTC)

Zh-tw for i18n
Well. It's a nice extension.--Roc michael 10:42, 16 May 2008 (UTC)
 * Traditional Chinese translation.

Fatal Error
I now get this message:

Fatal error: Class 'UserrightsPage' not found in /extensions/UserRightsList/SpecialUserRightsList.body.php on line 3

Sorry to be a pain. MW version - 1.10.1 PHP - 5.2.5 MySQL - 4.1.22


 * --Adam 09:50, 20 May 2008
 * It looks like MW changed the way the regular user rights form works in 1.12. I tried a quick patch to see if it would work in 1.10, but that didn't work. Sorry, you may need to update to 1.12. --JimHu 22:54, 25 May 2008 (UTC)

Doesn't Work for Me
Doesn't work for me. When I add the code into LocalSetings.php, my wiki pages won't come up anymore. Any ideas? Im running Mediawiki v.1.93 Mysql 5.051a, PHP5.2.5
 * I just made a version that should work with 1.9.3. Download it here.  I made it by modifying version 0.5, which requires MW classes that were not in earlier versions.  It is a quick and dirty patch, but it worked on 1.9.3 and 1.10 on my laptop --JimHu 07:59, 29 May 2008 (UTC)


 * Appreciate the update, but your link doesn't work. Maybe you can post the code.  Thanks

It doesn't work for me too on 1.13alpha --Bisato 09:25, 29 May 2008 (UTC)


 * "Doesn't work" isn't very useful in terms of debugging. White screen of death?  Doesn't show up in the Special page menu? etc.  Anything in the error logs?  I'll download 1.13 and see if I can reproduce the problem.
 * Please include more details and I'll see if I can figure out the problem. --JimHu 15:23, 29 May 2008 (UTC)
 * OK, I tried 1.13, and it doesn't work for me either. It seem like the whole Special Page setup is changing.  --JimHu 18:43, 29 May 2008 (UTC)
 * Update - patched for 1.13a in version 0.51. --JimHu 21:29, 29 May 2008 (UTC)

Could you re-upload the UserRightsList_pre12.tgz file? It has just 52 bytes and is blank for me. --85.158.137.195 09:10, 23 July 2008 (UTC)

Works fine with MW 1.11.0
Nice Extension, Works fine. My environment: --Roc michael 22:23, 26 May 2008 (UTC)
 * MediaWiki: 1.11.0
 *  UserRightsList (version 0.3) 
 * Win XP
 * The AppServ Open Project - 2.5.7 for Windows
 * Apache Web Server Version 2.2.3
 * PHP Script Language Version 5.1.6
 * MySQL Database Version 5.0.24a
 * Are you running the current version? It shouldn't work in 1.11! --JimHu 23:01, 26 May 2008 (UTC)
 * oops.. poor reading comprehension...

Errors After Adding This Extension
First of all let me just say that this looks like a great extension and I'm fairly new to administering Mediawiki so perhaps the problem is on my side somewhere. After I added this and went the Special Pages I got a non-fatal error of:

Strict Standards: Non-static method UserRightsList::loadMessages cannot be called statically in C:\Web\wiki\includes\Hooks.php on line 113

I was still able to go to the User Rights page and I was provided with another non-fatal error of:

'''Strict Standards: date [function.date]: It is not safe to rely on the system's timezone settings. Please use the date.timezone setting, the TZ environment variable or the date_default_timezone_set function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Chicago' for '-5.0/DST' instead in C:\Web\wiki\extensions\UserRightsList\SpecialUserRightsList.body.php on line 173'''

I am currently using:

MediaWiki 1.12.0 PHP 5.2.6 (apache2handler) MySQL 5.0.51b-community-nt

with UserRightsList (Version 0.41)

Cameron --63.160.176.134 17:21, 29 May 2008 (UTC)

Patch for UserRightsList
Hello. I've created a patch for this extension - it adds Czech localisation and fixes little PHP error. The patch is on my website here. Thanks in advance for any reactions.  mgrabovský  | talk  (DJ Jeri)   MW Support Team  19:52, 29 May 2008 (UTC)
 * Here is new patch, which works with 0.51.  mgrabovský  | talk  (DJ Jeri)  [[Image:Tournesol.png|25px]] MW Support Team  09:47, 31 May 2008 (UTC)

$wgAddGroups/$wgRemoveGroups Issue
I have been playing with the $wgAddGroups/$wgRemoveGroups to mimic a group leader type user.

We have a 'Red' group and 'Red-gl' group (gl means Group Leader). I added the following to LocalSettings.php :

$wgAddGroups['Red-gl'] = array ('Red'); $wgRemoveGroups['Red-gl'] = array ('Red');

Once I assigned a user the the 'Red-gl' group they could add/remove this group to/from users via the Uswer Rights Management special page. Thus manage their own group.

The UserRightsList extension does not show any users for the group leader of 'Red-gl' to manager. Based on the usage I assume it is because they did not create the user account. Did you plan for this extension to be able to perform the action based on $wgAddGroups/$wgRemoveGroups?

I saw where you had some discussions on:

http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/38406/focus=38424

--Wolcott 20:35, 29 July 2008 (UTC)


 * Answer to my own question. You are handling the $wgAddGroups, $wgRemoveGroups variables correctly.  My issue was the constraint you had that you could only modify users that you had created if you did not have the userrights permission.  So I have changed the code to allow a "Group  Leader" to add/remove any user to/from the group that they manage.

//if($wgUser->isAllowed('userrights')){ $table = array($this->user_table); $conds = array; //}else{ //	$table = array($this->user_table,'logging'); //	$conds = array('log_title = user_name', 		//		"log_type = 'newusers'",		//		"log_user = '".$wgUser->getID."'"); //}
 * I now retrieve all users. The special page will only show up if you have the userrights permission or you are in a group that has addGroup or removeGroup configured.  Might be nice to have a configuration variable that allows you to restrict the modification only to the users that you created ($wgUserRightListCreatedUsersOnly = true).  This should open the extension to a larger audience.


 * --Wolcott 21:22, 30 July 2008 (UTC)


 * One other minor patch to fix an undefined variable when no users are returned to manage. At the bottom of the function findMyUsers in the file SpecialUserRightsList.body.php.

function findMyUsers{ ...       ...

$results = $dbr->select($table, $vars, $conds, __METHOD__, $options); $this->num = $dbr->numRows($results);

// [MOD: JDS, 07-30-2008, CEW] - Also test for no rows. $arr not initialized and thus when no users // are fetched $arr not assigned. //if (!$results) return array; if (!$results || $this->num == 0) return array;

while( $x = $dbr->fetchObject ( $results ) ) { $arr[] = get_object_vars($x); }	return $arr; }


 * --Wolcott 13:41, 31 July 2008 (UTC)

User Rights List show in Special Pages when not logged in
The User Rights List option shows on the Special Pages when you are not logged in. I changed the following code in SpecialUserRightsList.body.php:

public function userCanExecute( $user ) { global $egUserRightsListChGrp, $wgAddGroups, $wgRemoveGroups; // [MOD: JDS, 07-30-2008, CEW] - Changed code. If the token is set then loop. //if (!isset($egUserRightsListChGrp)) return true; <-- Don't return true, return parent::userCanExecute( $user );

if (isset($egUserRightsListChGrp)) { foreach ($egUserRightsListChGrp as $group=>$chgrps){ foreach ($chgrps as $grp)	$wgAddGroups[$group][] = $grp; foreach ($chgrps as $grp)	$wgRemoveGroups[$group][] = $grp; }   }    return parent::userCanExecute( $user ); }

--Wolcott 22:30, 30 July 2008 (UTC)

SpecialPages Grouping
Hi, I suggest adding $wgSpecialPageGroups['UserRightsList'] = 'users'; after $wgSpecialPages['UserRightsList'] = 'UserRightsList'; in UserRightsList.php to make it show up in the Users and rights group on SpecialPages

--83.119.78.92 11:42, 27 August 2008 (UTC)