Cross-wiki userrights should use groups from target wiki instead local wiki
OpenPublic

Description

Author: dungodung

Description:
Some wikis, e.g. Hungarian Wikipedia (see bug 12085), have a patroller user group and bureaucrats on those projects can place users in that group and remove them from it. However, stewards aren't able to do the same. Even though it is quite unlikely that stewards would need to change that group, there should be a patroller group (if nothing, then at least for consistency's sake) in the Userrights interface for stewards when dealing with wikis that do have that user group. This shouldn't be too hard to fix, I imagine.


Version: 1.14.x
Severity: normal

bzimport set Reference to bz12518.
bzimport created this task.Via LegacyJan 5 2008, 6:09 PM
bzimport added a comment.Via ConduitJan 7 2008, 2:56 PM

dungodung wrote:

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.

Pathoschild added a comment.Via ConduitJan 7 2008, 7:46 PM

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

bzimport added a comment.Via ConduitJan 8 2008, 10:48 AM

dungodung wrote:

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?

brion added a comment.Via ConduitJan 9 2008, 12:37 AM

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.

bzimport added a comment.Via ConduitJan 13 2008, 10:13 AM

dungodung wrote:

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.

bzimport added a comment.Via ConduitJan 23 2008, 10:09 AM

dungodung wrote:

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.

brion added a comment.Via ConduitJan 30 2008, 9:03 PM

Couple ways around this:

  1. Have the same groups everywhere.
  1. Have available groups listed in the DB instead of config.
  1. Read the remote config data out of site configuration object (this is somewhat un-pretty with the current setup)
  1. Use some API thingy to fetch remote list of available groups (wouldn't work for private wikis)
vvv added a comment.Via ConduitJan 31 2008, 5:25 PM

(In reply to comment #7)

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

Why?

bzimport added a comment.Via ConduitFeb 1 2008, 12:37 AM

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.

vvv added a comment.Via ConduitFeb 1 2008, 4:03 AM

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

bzimport added a comment.Via ConduitFeb 9 2008, 6:31 PM

dungodung wrote:

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.

werdna added a comment.Via ConduitAug 17 2008, 9:39 AM

Generalising title further.

werdna added a comment.Via ConduitAug 17 2008, 9:39 AM
  • Bug 15193 has been marked as a duplicate of this bug. ***
brion added a comment.Via ConduitAug 19 2008, 5:42 PM

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.

vvv added a comment.Via ConduitAug 19 2008, 6:10 PM

(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

werdna added a comment.Via ConduitOct 24 2008, 11:50 PM
  • Bug 16099 has been marked as a duplicate of this bug. ***
werdna added a comment.Via ConduitJun 18 2009, 9:16 AM
  • Bug 19272 has been marked as a duplicate of this bug. ***
werdna added a comment.Via ConduitJul 27 2009, 4:17 PM

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

bzimport added a comment.Via ConduitDec 31 2009, 5:16 AM

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?

bzimport added a comment.Via ConduitFeb 15 2010, 6:57 AM

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.

Krenair added a comment.Via ConduitDec 1 2012, 12:23 AM

Gerrit change 36330

bzimport added a comment.Via ConduitDec 1 2012, 7:37 AM

quentinv57 wrote:

Many thanks for fixing this bug, Krenair.

Krenair added a comment.Via ConduitJan 1 2013, 4:19 AM

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

Snowolf added a comment.Via ConduitJan 16 2013, 8:11 PM

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.

bzimport added a comment.Via ConduitFeb 1 2013, 7:24 PM

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

Aklapper added a comment.Via ConduitMar 25 2013, 4:24 PM

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

Krenair added a comment.Via ConduitMar 25 2013, 5:15 PM

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.

Snowolf added a subscriber: Snowolf.Via WebNov 24 2014, 4:06 PM
werdna removed a subscriber: werdna.Via WebDec 10 2014, 5:45 PM
Qgil added a subscriber: Qgil.Via WebJan 12 2015, 12:07 PM

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

gerritbot added a subscriber: gerritbot.Via ConduitFeb 14 2015, 3:39 PM

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

Add Comment