Obsolete behavior MAY be removed after it has been hard deprecated for three months in the development version (the master branch) as well as in one major release

Beware, -grep is already reserved for pagegenerators:

class HarvestRobot(ConfigParserBot, WikidataBot):
    update_options = {
        'always': True,
        'create': False,
        'exists': '',
        'islink': False,
        'multi': False,
    }

The bot always runs as if -always was provided. The change would be trivial, but it could break e.g. bots via repeated jobs on Toolforge.

In T130439#7995727, @Quiddity wrote:

Would this be an accurate summary?

A new user_global_editcount variable can be used in abuse filters to avoid affecting globally active users.

(Drafts always appreciated!)

This task seems straightforward, but it involves both frontend and backend and also both modern and legacy interfaces. Also, things have changed a lot since T98941#3333468.

The test was created in https://gerrit.wikimedia.org/r/c/mediawiki/core/+/773927.

In T302140#7795751, @matej_suchanek wrote:

In T302140#7795717, @matej_suchanek wrote:

Could you provide some suggestions here? I'm familiar with PHP but not all that familiar with the testing portion.

Apparently, the test suite needs to be updated as well. The test correctly asserts that the reverted revisions are "autopatrolled", but this is what is supposed to change.

In fact not. The test actually asserts the status of the newest revision, not the reverted one(s). So line 178 should not be changed.
The test should probably assert the status of the reverted one(s) anyways.

It makes me wonder now whether all reverted changes should be marked as manually patrolled if they were autopatrolled...

This would probably help us solve several tasks around filter privacy (see the workboard on AbuseFilter). T174862: Special:AbuseLog should not show log entries of private filters is a similar proposal, but there were some concerns about transparency. I'm not sure myself, too.

In T309571#7971196, @Xaosflux wrote:

That is where the "examine" function on recent changes can be extremely helpful, so you can see the contents of each of those sections.

In T309665#7972445, @Daimona wrote:

@matej_suchanek @Huji Do you think this proposal makes sense, or am I missing something obvious?

Both SpecialChangeEmail and SpecialCreateAccount (via LoginSignupSpecialPage) use HTMLFrom with 'type' => 'email', but this is just an alias for HTMLTextField which does not validate the input in any way. Therefore, both pages do the validation themselves using Sanitizer::validateEmail which already has some technical debt (TODO). Maybe this all could now be unified and enhanced with length validation. Hope this helps.

I think you may need to use added_lines_pst instead of added_lines.

Sounds like T243615: The "thanks" and "undo" links on diffs have same requirements but different conditional appearance.

See also T261744: Introduce ThrottleStore.

I think this was solved by T301904 and T301247.

whether it's external (with getWikiId())

This method is just the tip of the Linker iceberg: ::userToolLinks, ::userToolLinksRedContribs, ::userTalkLink, etc. have the same pattern, and some of them are wrappers (or wrappers of wrappers). So

The chain of calls seems to be:

• SpecialCreateLocalAccount::onSubmit (CA)
• CentralAuthForcedLocalCreationService::attemptAutoCreateLocalUserFromName
• CentralAuthUtilityService::autoCreateUser
• AuthManager::autoCreateUser (core)
• AbuseFilterPreAuthenticationProvider::testUserForCreation/::testUser (AF)
• RunVariableGenerator::getAccountCreationVars

Looks like this could have the same root cause as T299896.

Removed in 071f87bf12a60edda23a4490d42b26c374d48a6e.

You are right, I must have once convinced myself about that.

For your convenience, variables related to users are set in VariableGenerator::generateUserVars and computed in LazyVariableComputer.

It seems the only realistic immediate solution is to abandon the problematic logging query (that counts rows and is not fully indexed) and instead make a boolean query to archive using ArchivedRevisionLookup::hasArchivedRevisions. I left some comments on https://gerrit.wikimedia.org/r/c/530949 that can be used for guidance (or rebased).

The Authority interface gives us now multiple options to solve the "not making this user be a sysop" part:

UI.input_list_choice does not handle the default from self.input(...):

Fixing in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Echo/+/779461.

This is interesting because the unit/ directory in AbuseFilter has never been written in uppercase.

Ah, here we are: T297754: CVE-2022-28204: Whatlinkshere of heavily used properties in wikidata can be easily utilized as a DDoS vector.

Not everything is done, some methods are stubs that just raise an error.

This could have been fixed by T303060.

For reference, I made the above patch after uncovering the "manual patrol status overwrite" bug in T302140.

In T302140#7799871, @MisterSynergy wrote:

In T302140#7795751, @matej_suchanek wrote:

It makes me wonder now whether all reverted changes should be marked as manually patrolled if they were autopatrolled...

Why so?

The rc_patrolled status of autopatrolled edits (i.e. rc_patrolled=2) should never be changed. These edits have been made by experienced users, thus they do not need to show up in the pipeline of patrollers. 0 -> 1 should be the only possible path.

In T302140#7795717, @matej_suchanek wrote:

Could you provide some suggestions here? I'm familiar with PHP but not all that familiar with the testing portion.

Apparently, the test suite needs to be updated as well. The test correctly asserts that the reverted revisions are "autopatrolled", but this is what is supposed to change.

So what's left?