Last modified: 2011-06-26 04:12:59 UTC
$wgFlaggedRevsAutopromote serves a very similar purpose to $wgAutopromote, but it's restricted to the 'editor' group. Each system implements a bunch of features the other doesn't. The features of $wgFlaggedRevsAutopromote should be merged into $wgAutopromote, and the former should be dropped (or rather reinterpreted in terms of $wgAutopromote, for back-compat). Some features of $wgFlaggedRevsAutopromote aren't feasibly implementable on every User::getEffectiveGroups() call, but you could add some new mode that works using explicit groups instead of implicit, and is only checked on certain events like edit.
Created attachment 7660 [details] MediaWiki-side patch (discussion which resulted in filing the bug: http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/49447) I have written the first patch, i.e. the one on MediaWiki core side. The autopromotion can be now done like: $wgHooks['ArticleSaveComplete'][] = array ( 'Autopromote::autopromoteOnceHook', array( 'somegroup' => array(APCOND_EDITCOUNT, 100) ) ); The format of conditions is the same as $wgAutopromote. The differences are: * The group can be removed from a user via Special:UserRights. * The user is not autopromoted to the groups he/she has once belonged to. * The user won't lose the group automatically if he/she no longer meets the criteria. * The Autopromote::autopromoteOnceHook() function can be assigned to any hook so autopromotion is "only checked on certain events". The function simply calls a new method User::autopromoteOnce() on $wgUser so if there's such need a custom function may be written. My autopromotion mechanism is separate from $wgAutopromote, though it uses the same format of conditions. And I had to create a new database table: user_former_groups. It's actually a clone of user_groups but stores the groups the user has once belonged to, not necessarily belongs now. I haven't tested if the table is created properly on anything different then MySQL (though it should work on sqlite and postgres because it's actually copy-pasted user_groups).
The user attributes/tally table (flaggedrevs_autopromote) should be in the core too, so that extensions are not adding new tables for every new attribute they want to check.
Is this patch still being maintained?
It can be, if it's needed. Besides, I'm not sure if the way of attaching an autopromotion to a hook was the best idea of mine...
Created attachment 8471 [details] MediaWiki-side patch, updated Patch updated to the latest svn revision.
Should go at the end of the update list under 1.18, not in the middle of the 1.17 list.
(In reply to comment #4) > It can be, if it's needed. > Besides, I'm not sure if the way of attaching an autopromotion to a hook was > the best idea of mine... It can be useful to only check on certain action for performance reasons. I've looked at the patch diff above, which is fairly sane. I'm thinking this should be committed soon so that a broader audience will look at it. With the AutopromoteCondition hook, there is already a way for extensions to add conditions.
(In reply to comment #5) > Created attachment 8471 [details] > MediaWiki-side patch, updated > > Patch updated to the latest svn revision. Do you have commit access btw?
This patch won't apply well at all with SVN (I can tell from the file names) :/
(In reply to comment #9) > This patch won't apply well at all with SVN (I can tell from the file names) :/ Nevermind, worked around it. Applied in r90749.
Largely dealt with in r90816. A few APCONDs could perhaps be moved to core though.
