Last modified: 2014-09-02 20:41:43 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 12518 - Cross-wiki userrights should use groups from target wiki instead local wiki
Cross-wiki userrights should use groups from target wiki instead local wiki
Status: PATCH_TO_REVIEW
Product: MediaWiki
Classification: Unclassified
User login and signup (Other open bugs)
1.14.x
All All
: Low normal with 6 votes (vote)
: ---
Assigned To: Alex Monk
: crosswiki
: 15193 16099 19272 (view as bug list)
Depends on:
Blocks: SWMT
  Show dependency treegraph
 
Reported: 2008-01-05 18:09 UTC by Filip Maljkovic [Dungodung]
Modified: 2014-09-02 20:41 UTC (History)
17 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Filip Maljkovic [Dungodung] 2008-01-05 18:09:01 UTC
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.
Comment 1 Filip Maljkovic [Dungodung] 2008-01-07 14:56:36 UTC
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.
Comment 2 Jesse (Pathoschild) 2008-01-07 19:46:22 UTC
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).
Comment 3 Filip Maljkovic [Dungodung] 2008-01-08 10:48:19 UTC
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?
Comment 4 Brion Vibber 2008-01-09 00:37:59 UTC
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.
Comment 5 Filip Maljkovic [Dungodung] 2008-01-13 10:13:13 UTC
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.
Comment 6 Filip Maljkovic [Dungodung] 2008-01-23 10:09:31 UTC
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.
Comment 7 Brion Vibber 2008-01-30 21:03:35 UTC
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)
Comment 8 Victor Vasiliev 2008-01-31 17:25:40 UTC
(In reply to comment #7)
> 4) Use some API thingy to fetch remote list of available groups (wouldn't work
> for private wikis)

Why?
Comment 9 Casey Brown 2008-02-01 00:37:44 UTC
(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.
Comment 10 Victor Vasiliev 2008-02-01 04:03:05 UTC
(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?)
Comment 11 Filip Maljkovic [Dungodung] 2008-02-09 18:31:49 UTC
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.
Comment 12 Andrew Garrett 2008-08-17 09:39:15 UTC
Generalising title further.
Comment 13 Andrew Garrett 2008-08-17 09:39:35 UTC
*** Bug 15193 has been marked as a duplicate of this bug. ***
Comment 14 Brion Vibber 2008-08-19 17:42:20 UTC
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.
Comment 15 Victor Vasiliev 2008-08-19 18:10:19 UTC
(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
Comment 16 Andrew Garrett 2008-10-24 23:50:36 UTC
*** Bug 16099 has been marked as a duplicate of this bug. ***
Comment 17 Andrew Garrett 2009-06-18 09:16:44 UTC
*** Bug 19272 has been marked as a duplicate of this bug. ***
Comment 18 Andrew Garrett 2009-07-27 16:17:57 UTC
It would be simple to apply this patch and develop some way of using wgGroupPermissions properly instead of strange override arrays.
Comment 19 Mike.lifeguard 2009-12-31 05:16:10 UTC
(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?

Comment 20 Mike.lifeguard 2010-02-15 06:57:03 UTC
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.
Comment 21 Alex Monk 2012-12-01 00:23:53 UTC
Gerrit change #36330
Comment 22 Quentinv57 2012-12-01 07:37:28 UTC
Many thanks for fixing this bug, Krenair.
Comment 23 Alex Monk 2013-01-01 04:19:44 UTC
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."
Comment 24 Snowolf 2013-01-16 20:11:16 UTC
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.
Comment 25 Quentinv57 2013-02-01 19:24:44 UTC
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...
Comment 26 Andre Klapper 2013-03-25 16:24:37 UTC
There are a few people added as reviewer in Gerrit - probably best to ping there, but Alex has already commented on Tim's review.
Comment 27 Alex Monk 2013-03-25 17:15:33 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links