Cross-wiki userrights should use groups from target wiki instead local wiki
Open, LowPublic

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

dungodung created this task.Jan 5 2008, 6:09 PM

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?

brion added a comment.Jan 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.

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.

brion added a comment.Jan 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.Jan 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?

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

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. ***
brion added a comment.Aug 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.Aug 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

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

werdna removed a subscriber: werdna.Dec 10 2014, 5:45 PM
Qgil added a subscriber: Qgil.Jan 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?

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

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 27 2015, 5:36 AM

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

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

Krenair removed Krenair as the assignee of this task.Sep 19 2015, 1:52 AM
revi added a subscriber: revi.Dec 11 2015, 5:50 AM
Meno25 removed a subscriber: Meno25.Feb 22 2016, 6:19 PM
Restricted Application added a subscriber: JEumerus. · View Herald TranscriptFeb 22 2016, 6:19 PM

Add Comment