Wikimedia Bugzilla is closed!

This, apparently, extends to any other user right. e.g. editor, reviewer and povwatch rights on testwiki. I'm guessing the current rights pool is static for all wikis. It should take the list of available rights from the wiki when the steward hits "Edit User Groups" button.

If I recall correctly, the userrights interface on Meta only recognizes rights defined on Meta (which is the default set of rights for all wikis).

For the record, here is a script-generated list of all the wikis that have some non-default user groups: http://tools.wikimedia.de/~dungodung/availrights

The list isn't very large and maybe it could be maintained somewhere, in case there's no easy way to do this? Namely, this would require calling User::getAllGroups() for the project at hand, and as I get it, Special:Userrights only goes to the DB (to fetch the permissions of the user, but only those from the default pool of permissions). Alternate solution could be to add a table of all the available userrights in every DB (with the possibility to index everyone with the said right, which could, additionally, help speed up the Special:Listusers page).

Is any of this feasible?

There's no table, and $wgGroupPermissions isn't set in a clean way in the InitialiseSettings array, so this would probably require some reconfiguration or other trickery.

After talking to Tim on IRC, I've concluded that the easiest way to solve this is to make all these groups (patroller, autopatrolled and now rollbacker) global, just like transwiki group was made recently.

mysql> use enwiki_p;
mysql> SELECT DISTINCT ug_group FROM user_groups;
+------------+
| ug_group   |
+------------+
| bot        | 
| bureaucrat | 
| checkuser  | 
| founder    | 
| import     | 
| oversight  | 
| rollbacker | 
| sysop      | 
+------------+
8 rows in set (0.07 sec)

This query lists userrights that are actually used on the project in question. If this list were combined with the default list of user rights, it would yield better results, IMO.

Couple ways around this:

1) Have the same groups everywhere.

2) Have available groups listed in the DB instead of config.

3) Read the remote config data out of site configuration object (this is somewhat un-pretty with the current setup)

4) Use some API thingy to fetch remote list of available groups (wouldn't work for private wikis)

(In reply to comment #7)
> 4) Use some API thingy to fetch remote list of available groups (wouldn't work
> for private wikis)

Why?

(In reply to comment #8)
> (In reply to comment #7)
> > 4) Use some API thingy to fetch remote list of available groups (wouldn't work
> > for private wikis)
> 
> Why?
> 

api is disabled on private wikis due to the possible security vulnerability.

(In reply to comment #9)
> (In reply to comment #8)
> > (In reply to comment #7)
> > > 4) Use some API thingy to fetch remote list of available groups (wouldn't work
> > > for private wikis)
> > 
> > Why?
> > 
> 
> api is disabled on private wikis due to the possible security vulnerability.
> 

Also, we should note that Special:Userrights doesn't know URIs of other wikis (does it?)

Generalized the bug title to all non-global user rights.

Also, I've made a script that dynamically checks for projects with additional user rights: http://tools.wikimedia.de/~dungodung/cgi-bin/availrights

And re comment #7: 2) seems to be the cleanest way (and also quite an easy one) to do it, IMHO.

Generalising title further.

*** Bug 15193 has been marked as a duplicate of this bug. ***

r39582 was labeled as "(bug 12518) Interwiki userrights now reflects remote groups, not local groups."

I've reverted this in r39650 as it won't actually work; it checks the InitialiseSettings.php settings array for $wgGroupPermissions, but we don't set the group permissions that way. Instead, a couple of override arrays are set which get applied on top of the default $wgGroupPermissions.

(In reply to comment #14)
> r39582 was labeled as "(bug 12518) Interwiki userrights now reflects remote
> groups, not local groups."
> 
> I've reverted this in r39650 as it won't actually work; it checks the
> InitialiseSettings.php settings array for $wgGroupPermissions, but we don't set
> the group permissions that way. Instead, a couple of override arrays are set
> which get applied on top of the default $wgGroupPermissions.
> 

That's why Andrew also modified $wgConf in r39577

*** Bug 16099 has been marked as a duplicate of this bug. ***

*** Bug 19272 has been marked as a duplicate of this bug. ***

It would be simple to apply this patch and develop some way of using wgGroupPermissions properly instead of strange override arrays.

(In reply to comment #15)
> That's why Andrew also modified $wgConf in r39577

Does that mean it should be un-reverted? Or is a different solution still required?

Please don't set bugs as RESOLVED LATER without good reason. Generally, that should be done only by a developer who is actually involved with fixing the bug.

Gerrit change #36330

Many thanks for fixing this bug, Krenair.

Chris Steipp's comment on the Gerrit change: "This looks ok to me, but someone who's a little more familiar with this bug should take a look and make sure this addresses all the issues."

Any chance we can find somebody else to look over and see if the patch can be approved? This would very very useful to have for us stewards.

Any progress ?

If nobody can check it, I could take a look myself but I'm not sure to be the kind of people Krenair is waiting for...

There are a few people added as reviewer in Gerrit - probably best to ping there, but Alex has already commented on Tim's review.

Chris and Tim discovered that WMF's config doesn't work with this patch, so other people will either have to find a different way to do it or we need to change how WMF's config sets up group permissions. I suspect there will be issues with things like extensions.