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)

I get exactly the same error message, I'm using MW version 1.13.2

would be cool if i could get your extension to work

Greets

Sonstwer 17-April-2009

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)

pl translation
hi this is Polish translation for extension btw nice extension --Szczurex 19:04, 4 November 2008 (UTC)

German translation AND localized "Save" button
Just added the function to localize the text of the save button:

In SpecialUserRightsList.body.php change the line



to



and add the following line in SpecialUserRightsList.i18n.php for each language within the array (example is 'de')

'savebutton' => 'Speichern',

And here is the German translation including "savebutton - extension":

'de' => array(               'userrightslist' => 'Benutzerrechteliste',                'nousersfound' => 'Keine benutzer gefunden zum Bearbeiten.',                'regbefore' => 'registriert vor:',                'regafter' => 'registriert nach:',                'savebutton' => 'Speichern',                'usernamelike' => 'Name suchen:'),

Doesn't Work with MW 1.14 ??
The User Right List doesn't show up on the special pages, although the extension shows up on the "version" page and I'm SysOP and Bureaucrat. is there any special setting I could have forgotten? --Malte Mertz 14:02, 27 February 2009 (UTC)

Hi, if you change in the SpecialUserRightsList.body.php in line 11 list ($this->user_table,$this->user_groups_table) = wfGetDB->tableNamesN('user','user_groups'); to list ($this->user_table,$this->user_groups_table) = wfGetDB( DB_SLAVE )->tableNamesN('user','user_groups');

it should work, for me it does. --193.27.220.14 14:54, 6 March 2009 (UTC)

Changes to see users real name in the list
Two lines need to be changed to and line 114 from to Heth
 * SpecialUserRightsList.body.php version 0.41
 * line 263 from

User List filter by group membership
How can I filter the User list by the group membership user? - added this feature in 0.52 --JimHu 17:15, 14 May 2009 (UTC)

Cascading Rights
Hi there im running this extension on MW1.15. When i start to add permissions to users and then save the page user under a user above gain the same rights. An example User A has Sysops rights and user B has a specific group right. But when i save the page user B gains the Sysops right as well. Any ideas as to why this happens? This extension is very useful as i have a few thousand users and at least 10 different groups. Adam 14:09, 17 July 2009 (UTC)

Hi, I am running this extension under MW1.14.1 and have observed the same behaviour. It would be great to have a fix for this since I think that this problem gets more severe the more registers users are on a wiki. Cheers --kgh 20:18, 17 October 2009 (UTC)
 * Hi guys. Not sure why I'm not getting watch list notices from this page, but I just saw this thanks to kgh's post to my user page.  I'm running it on 1.14 and I don't see this problem.  Can you send me more info? --JimHu 20:31, 18 October 2009 (UTC)

Hi Jim, no worries. :-) I have uploaded a file to visualise the problem. It is a German installation, but that is irrelevant in this case. The file displays the current and intended situation on the wiki.




 * 1) Before I started to use your tool the users #1 and 3 were only sysops, user 2 was sysop and bureaucrat and user 4 was sysop, bureaucrat and bot.
 * 2) I wanted to provide user #2 with the additional rights of widgeteditor and ticked the square.
 * 3) After saving the changes I found out that the system also provided user #3 with additional rights for bureaucrat and widgeteditor.
 * 4) I then removed the rights for user #3 with the mediawiki build-in special page 'userrights' It was not possible to do it with 'userrightslist'
 * 5) After that I wanted to provide user #4 with the additional rights of sysadmin and ticked the square.
 * 6) After saving the changes I realised that user #3 was again provided with additional rights for bureaucrat and widgeteditor, but not sysadmin
 * 7) I had again to remove the rights for user #3 with the mediawiki build-in special page 'userrights' to only sysop

This is what I observed. No changes were made to the privileges of user #1. I think that it might have something to do with the fact that some user groups have partially the same privileges. This partial overlap might be the source of the problem with in fact also confuses build-in special page 'userrights'. However were must be another reason to explain the behaviour of the tool with regard to user #1. Hopefully this description helps to grasp the situation. Cheers --kgh 00:05, 19 October 2009 (UTC)

Having same problems on 1.15.1 193.2.84.34 14:01, 2 April 2010 (UTC)

Bug report / Conflict with DPL
I'm running MW 1.15.1, v0.52 of this extension and the latest version of DPL.

The trouble is, that when I have any DPL-query on a page, some elements of a stylesheet isn't functioning. Not exactly sure what goes on, but the layout is messed up. This is, however, only the case for anonymous users.

I commented out all my extensions in LocalSettings, searching for the conflict - and I found that it was UserRightsList.

I'd very much like to keep both extensions, so I narrowed it down further. The following line in UserRightsList.php seems to be the cause of my troubles:

$wgHooks['LoadAllMessages'][] = 'UserRightsList::loadMessages'; Not understanding it entirely, I'd like to know what significance this single line holds and if there's a way to do without and retain the functionality of this great administrative tool. I've commented it out and things seem to be working alright. Still, the line must be there for a reason :)

--Martin, Denmark

Deutschsprachige Übersetzung für SpecialUserRightsList.i18n.php
Hi Leute, die obige Datei enthält aktuell (Stand: 17. Oktober 2009) noch keine deutsche Übersetzung. Einfach, je nach Sprache der MediaWiki-Installation einen der beiden Codeblöcke in die Datei einfügen:

'de' => array(               'userrightslist' => 'Nutzerrechteverwaltung in Listenform',                'nousersfound' => 'Zur Auswahl wurden keine Nutzer gefunden',                'regbefore' => 'Angemeldet nach',                'regafter' => 'Angemeldet vor',                'usernamelike' => 'Zeige Nutzer ab:'        ),

'de-formal' => array(               'userrightslist' => 'Nutzerrechteverwaltung in Listenform',                'nousersfound' => 'Zur Auswahl wurden keine Nutzer gefunden',                'regbefore' => 'Angemeldet nach',                'regafter' => 'Angemeldet vor',                'usernamelike' => 'Zeige Nutzer ab:'        ),

Viele Grüße --kgh 20:00, 17 October 2009 (UTC)

PS @Jim Hu: Hi, perhaps you could incorporate this localisation in the standard snapshot of this file. Cheers and thank you --kgh 20:00, 17 October 2009 (UTC)

Not working with MW 1.16.0
Version 0.52 of this extension is not working with MW 1.16.0. When submitting changes to the user rights list you receive a HTTP 500 error and the changes are not captured.

--Dgennaro 16:03, 19 August 2010 (UTC)

Fatal error on save
I am using MW 1.16.0 an I get the following error when saving changed:

Fatal error: Cannot access protected property WebRequest::$data in /var/www/mediawiki-1.16.0/extensions/UserRightsList/SpecialUserRightsList.body.php on line 62

Any help on this issue is appreciated.

--Karlpicard 21:32, 2010 August 20

I am getting the same error and I would also really appreciate a fix.

--Apap 10:27, 31 August 2010 (UTC)
 * I have fixed this bug as well as another table rendering problem, see this diff for the changes I made to fix it for MW1.16.

--Nad 10:17, 2 September 2010 (UTC)

Thanks so much for the fix, works now!!

--Karlpicard 15:35, 2010 3 September 2010 (UTC)

Problem on MediaWiki 1.17
Just set this up on a fresh MW install with only the Semantic extension installed, so hopefully there should not be any conflict. The extension is recognized as installed if I go to the "Version" page, but when attempting to load the actual UserRightsList Special page I get a blank white screen. No error messages, and the MW page frame also does not load. My installation stats are: MW version 1.17.0, PHP 5.3.6, and MySQL 5.1.56. I've also added the code changes listed for 1.16 already, but those did not help.

I've used this extension before on previous versions of MW, and it's always been very useful. I'd really love to get it working again!


 * I get the following error with MW 1.17:

Fatal error: Call to undefined function wfOpenElement in E:\(...)\extensions\UserRightsList\SpecialUserRightsList.body.php on line 131
 * which is this line in pageTop:

$out .= wfOpenElement( 'form', array( 'method' => 'post', 'action' => $self->getLocalUrl ) );
 * No solution yet.
 * --24.246.73.140 22:08, 4 November 2011 (UTC)