Page MenuHomePhabricator

list=users&usprop=rights shows rights the user doesn't have
Closed, ResolvedPublic

Description

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.


Version: unspecified
Severity: normal

Details

Reference
bz29938

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 11:32 PM
bzimport set Reference to bz29938.

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