(In reply to comment #7)

4. Use some API thingy to fetch remote list of available groups (wouldn't work

for private wikis)

Why?

bugs wrote:

(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.

mike.lifeguard+bugs wrote:

(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?

mike.lifeguard+bugs wrote:

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

quentinv57 wrote:

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.

quentinv57 wrote:

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.

@Krenair, this is one of the oldest tasks assigned to someone. Are you planning to work on it, and is the current priority correct?

@Qgil, this is Patch-For-Review

Change 36330 had a related patch set uploaded (by Qgil):
Fetch cross-wiki user groups from target wiki instead of assuming local

https://gerrit.wikimedia.org/r/36330

Patch-For-Review

Change 36330 abandoned by Alex Monk:
Fetch cross-wiki user groups from target wiki instead of assuming local

https://gerrit.wikimedia.org/r/36330

Change 627792 had a related patch set uploaded (by DannyS712; owner: DannyS712):
[mediawiki/core@master] SpecialUserrights: Make use of UserGroupManager

https://gerrit.wikimedia.org/r/627792

Change 627792 merged by jenkins-bot:
[mediawiki/core@master] SpecialUserrights: Make use of UserGroupManager

https://gerrit.wikimedia.org/r/627792

Can't really proceed until T263207: The `UserrightsPage` class is not safe to extend is cleaned up

Change 762117 had a related patch set uploaded (by Zabe; author: Zabe):

[mediawiki/core@master] Fetch groups from target wiki on Special:Userrights

https://gerrit.wikimedia.org/r/762117

This is now blocked on T255213.

Change 762117 abandoned by Umherirrender:

[mediawiki/core@master] Fetch groups from target wiki on Special:Userrights

Reason:

Handled by Iade0cc0e75870ec64dd5f9e7a6929f031f9b5629

https://gerrit.wikimedia.org/r/762117

I wonder why we can't grant userrights to all stewards on all wikis via the global user group, if we can allow them to self-promote to local stewardship and essentially gain the same right. No hacks would be needed if we handle everything locally.

In T14518#11654861, @1F616EMO wrote:

I wonder why we can't grant userrights to all stewards on all wikis via the global user group, if we can allow them to self-promote to local stewardship and essentially gain the same right. No hacks would be needed if we handle everything locally.

We could, we chose not to. That isn't a technical limitation. Socially, stewards are not meant to act locally when a community can self-service - so we purposefully leave this off.

Change #1251483 had a related patch set uploaded (by Zabe; author: Zabe):

[mediawiki/core@master] Introduce UserGroupConfigReader to correctly load groups of other wikis

https://gerrit.wikimedia.org/r/1251483