Page MenuHomePhabricator

XTools shows users as autoconfirmed too early following change
Open, LowPublic

Description

In T418484, autoconfirmed was changed to be granted based on time since first edit, instead of registration. XTools is still calculating based on the old configuration, for instance this user was registered on 8 June, but first edited on 11 June. They will become autoconfirmed on the 15th, but XTools says they became autoconfirmed on the 12th.

XTools version: 3.24.8-b436ff31

Event Timeline

Oh well. This is the same kind of thing as T203315; again no solution but harcoding that accounts created between X and Y used that method, between Y and Z another one, since Z yet another one...
(Also, self-reminder: we need to figure out what the rule applied depends on. Is it account creation date? Say a user became autoconfirmed at time t-1 by the current rule then the rule gets changed at time t and now they're supposed to only become autoconfirmed at time t+1, what happens?)
We should also keep in mind T392551 and the wider work to function on third-party setups.
Settings for automatic rights can also be wiki-dependent (T321097 for something on ptwiki).

I'm thinking if we're going to do this we should create a new config file that could look something like (quick mockup, some of this is wrong I think):

global:
    autoconfirmed:
        -
            from: 0
            method: none
        -
            from: 20080521000000
            method: fromcreation
            edits: 10
            time: P4D
        -
            from: 20260505000000
            method: fromfirstedit
            edits: 10
            time: P4D
local:
    enwiki:
        extendedconfirmed:
            -
                from: 0
                method: none
            -
                from: 20160406000000
                method: fromcreation
                edits: 500
                time: P30D
[...]

and so on (maybe make that from: 0 method:none at the beginning of every right automatic?).

For most third-party wikis it should just look like:

global:
    autoconfirmed:
        -
            from: 0
            method: auto

where auto means doing what T392551 asks for (given $wgAutopromote).

The resulting config file wouldn't even be that long for Wikimedia, and I think it changes pretty rarely (else I'd have said make it a wikipage like the config for automated tools).

All of that's doable but I'm not sure it's our role to keep an up-to-date history of Wikimedia autopromote config.

Keeping an up-to-date history of the Wikimeida autopromote is config is madness… but on the other hand, XTools is meant to fill the gaps that MediaWiki can't. Perhaps a bit of madness naturally comes with that!

I don't necessarily want to encourage doing anything about this. Yet, if we did, it's worth mentioning we'd be the only source available for such data, which is kind of cool ;)

make it a wikipage like the config for automated tools

If we do move forward with it, I suggest this. Crowd-sourced all the way. It'll need the same kind of lengthy documentation, sensible defaults, etc., so people don't mess things up, but of all options presented this seems the most scalable and least headache-prone.

T392551 would be more about just fetching the current config (scraping noc.wikimedia.org is very faux-pas and WMF-centric), while the community-maintained history would always supplement that.