Last modified: 2008-08-30 03:01:45 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 12632 - {{NUMBERINGROUP}} magic word
{{NUMBERINGROUP}} magic word
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
unspecified
All All
: Normal enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
: schema-change
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-01-14 22:04 UTC by Anakin
Modified: 2008-08-30 03:01 UTC (History)
2 users (show)

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


Attachments

Description Anakin 2008-01-14 22:04:47 UTC
To complement {{NUMBEROFADMINS}}, how about a magic word for the number of users in each group?

For example: {{USERSINGROUP:sysops}}, {{USERSINGROUP:bureaucrats}}, {{USERSINGROUP:bots}}.

It's very similar to {{PAGESINNAMESPACE}}, and saves having to create separate magic words (or manually updated templates) for each case. For example, with the new rollback group on Wikipedia, User:Gurch created the {{NUMBEROFROLLBACKERS}} template (http://en.wikipedia.org/wiki/Template:NUMBEROFROLLBACKERS) to implement a count manually (which is what inspired me to post this idea), but templates are always a slightly awkward way of doing it, since they either need a bot or a manual update, and updating them wastes revisions in the database. A nice simple magic word would be perfect.

I was wondering what the overhead of such a magic word would be, but I don't think it would be too much at all; PAGESINNAMESPACE isn't enabled on Wikipedia because it requires a run of every page in the database, but NUMBEROFADMINS is, because it only runs through the much smaller table of group assignments, rather than the table of all users.

Good idea/stupid idea? :)
Comment 1 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-01-14 22:08:22 UTC
This would require tracking all groups; currently it's hard-coded to only track admins.  NUMBEROFADMINS does not scan the user_groups table.  That doesn't scale.  Rather, it retrieves a column from the one-row site_stats table, which contains a fixed set of info (number of pages, number of articles, number of users, number of admins, ...).  Probably this doesn't scale to arbitrary groups, so we might need a new table for this.
Comment 2 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-01-14 22:09:23 UTC
Also, {{NUMBERINGROUP}} is a clearer name.  Or we could give an optional parameter to {{NUMBEROFUSERS}} or something.  {{USERSINGROUP}} suggests it would give a list.
Comment 3 Anakin 2008-01-14 23:11:59 UTC
(Ooops, lol, I've just realised the alternate interpretation of the name I suggested: "USER SIN GROUP", reminds me of that "Admin is traitor" thing.)

I'm not terribly familiar with MediaWiki's internals, but there can't be more than about 2,500 group assignments even on all of the English wikipedia; would a table scan really affect the servers?

A whole new table, if it had to be used, would be a nuisance because it's an extra thing to have to manage and update. It would probably only need to be done in one place though, rebuilding the table info with a single SELECT/GROUP BY query in the user rights change code.
Comment 4 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-01-14 23:18:51 UTC
It's true that you'd just have to scan a few hundred to a couple thousand index leafs.  I don't know if that would be acceptable or not.  Even on the toolserver it manages to run in <10 ms, so probably it would be <<1 ms on the real servers.  Regardless, it might not do so well when we accumulate tens or hundreds of thousands of rollbackers in a couple of years.  It's best to do it right to begin with, all around, if it's to be done.
Comment 5 X! 2008-08-30 03:01:45 UTC
Fixed in r40116

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


Navigation
Links