Last modified: 2008-08-28 00:06:15 UTC
On enwiki, the user group rollbackers is enabled. So, a template was created (see URL), because there was no magic word for the amount of rollbackers. SQLBot currently updates it. I have submitted a patch, which updates SiteStats.php and Parser.php, creating that new magic word. I have tested it, and it works. All it needs is to be implemented. Thanks! Soxred93
Created attachment 4744 [details] Proposed patch
1) Your patch seems to mix up rollbackers and bureaucrats. It looks as though it will result in a fatal error, since you called a nonexistent function SiteStats::crats(). 2) The word 'rollbacker' must occur nowhere in the patch. We will not incorporate explicit references to usergroups that do not exist in the core software. Generalize this to a NUMBERINGROUP function or something, and it might be committed.
Created attachment 4745 [details] Better patch (used wrong patch)
Why not just have [[Template:NUMBEROFROLLBACKERS]] and have people update it manually whenever someone gets it? It worked for Pokémon.
It's still not acceptable to refer to enwiki-specific groups like that in core code. This also may be a performance issue for potentially very large groups like rollbacker. Over time I expect it will grow to tens of thousands or more, and all those index nodes will have to be scanned. If this feature is really desired, another usergroup table could be added to store the size of each usergroup, like the new category table, but that seems pretty excessive.
Ok, working on {{NUMBEROFGROUPUSERS:rollbacker}} now.
One thing you might not have noticed: This is for Wikimedia, not MediaWiki.
Corrected component. It should be MediaWiki.
Correct. All software changes are filed under either MediaWiki or MediaWiki extensions, because that's where the changes must be made. Wikimedia is only for configuration changes, which this is not. In principle, Wikimedia does not maintain live hacks: everything gets committed to the core software. (In practice some admins do maintain live hacks, which periodically get cleaned up and committed to avoid merge conflicts on svn up.)
Um? Any reason for RESOLVED LATER? If someone wants to work on this they can. LATER should usually be used on MediaWiki bugs for when the bug cannot be fixed now for some reason no matter what code we write (for instance, inadequate upstream support for something) but may be fixable at some later date.
Oh, sorry. I thought that meant like a withdrawal or something.
You can un-assign yourself using "Reassign bug to default assignee and add Default CC of selected component". That's not really resolving the issue, though, is it? It doesn't set it to RESOLVED, it sets it to NEW.
Created attachment 5219 [details] New patch, implementing {{NUMBERINGROUP}} parserfunction New patch: Instead of {{NUMBEROFROLLBACKERS}}, it has been changed to {{NUMBERINGROUP}} Usage: {{NUMBERINGROUP:(group)}} Raw: {{NUMBERINGROUP:(group)|R}}
Created attachment 5220 [details] Sigh, fix spaces
Applied in r40116
