llampak wrote:

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

attachment AutopromoteOnce.patch ignored as obsolete

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?

llampak wrote:

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

llampak wrote:

MediaWiki-side patch, updated

Patch updated to the latest svn revision.

Attached:

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?

Attached:

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.

Script wmf-auto-reimage was launched by dzahn on cumin1001.eqiad.wmnet for hosts:

mw2250.codfw.wmnet

The log can be found in /var/log/wmf-auto-reimage/201907172234_dzahn_204900_mw2250_codfw_wmnet.log.

Completed auto-reimage of hosts:

['mw2250.codfw.wmnet']

Of which those FAILED:

['mw2250.codfw.wmnet']