Last modified: 2011-07-18 21:29:18 UTC
Split from bug 29906: list=users&usprop=rights shows rights the user doesn't have Steps to reproduce: 1. Look into [[Special:Log/newusers]] to get the name of a new user. 2. http://en.wikipedia.org/w/api.php?action=query&list=users&ususers=Futbol%20vic&usprop=rights In this example we get rights shown like move and autoconfirmed which a new user definitely doesn't have. The groups are correct and I didn't find any edit to a semiprotected page by a new user though I can see autoconfirmed rights for all users in every project, so it seems like only the API shows nonsense.
This may have already been fixed in trunk quite a while back
if ( !isset( $data[$name]['rights'] ) ) { $data[$name]['rights'] = User::getGroupPermissions( User::getImplicitGroups() ); } On my dev wiki... User::getImplicitGroups() returns array 0 => string '*' (length=1) 1 => string 'user' (length=4) 2 => string 'autoconfirmed' (length=13) And the same on enwiki reedy@fenari:/home/wikipedia/common/php-1.17/maintenance$ php eval.php --wiki=enwiki > var_dump( User::getImplicitGroups() ); array(3) { [0]=> string(1) "*" [1]=> string(4) "user" [2]=> string(13) "autoconfirmed" } > Hell, it's hardcoded in DefaultSettings /** * Implicit groups, aren't shown on Special:Listusers or somewhere else */ $wgImplicitGroups = array( '*', 'user', 'autoconfirmed' ); > $user = User::newFromName( 'Reedy' ); > var_dump( $user->getEffectiveGroups() ); array(5) { [0]=> string(11) "abusefilter" [1]=> string(5) "sysop" [2]=> string(1) "*" [3]=> string(4) "user" [4]=> string(13) "autoconfirmed" } > $user = User::newFromName( 'Futbol_vic' ); > var_dump( $user->getEffectiveGroups() ); array(2) { [0]=> string(1) "*" [1]=> string(4) "user" } >
(In reply to comment #2) > Hell, it's hardcoded in DefaultSettings So, "INVALID"?
(In reply to comment #3) > (In reply to comment #2) > > Hell, it's hardcoded in DefaultSettings > > So, "INVALID"? No, it's still a bug, technically the API is calling the "wrong" function
r92477
