I would say the "action" (as understood by AbuseFilter) should not be "edit" though. Otherwise, as soon as we enable this feature, tons of filters will start to be triggered where they originally were not specifically meant to. The possible collateral is too high.

In other words, I think after this feature is enabled, filters that currently trigger on edits (not uploads or logs, but edits) should still continue to only be triggered for non-rollback edits. If you want them to also be triggered by rollbacks, you should somehow work action = 'rollback' into the rules.

In T262157#6438856, @Huji wrote:

I would say the "action" (as understood by AbuseFilter) should not be "edit" though. Otherwise, as soon as we enable this feature, tons of filters will start to be triggered where they originally were not specifically meant to. The possible collateral is too high.

I don't think it would have much collateral damage: many, if not all, filters already check permissions, and in order to use rollbacks a user must be privileged (e.g. rollbacker, sysop). However, I do think that it's a good idea to make it a different action, also given that we're going to use a different hook etc.

If you want them to also be triggered by rollbacks, you should somehow work action = 'rollback' into the rules.

+1

Considering for investigation, unsure if it's also suitable for implementation as part of the project.

Not sure if making this feature into a separate action is a good idea. There are three types of reverts out there (undo, rollback, manual) and this would just support one of these, which is rather incomplete. I'd rather propose for AbuseFilter to somehow receive the EditResult object related to the edit, so that all kinds of reverts are treated properly. Then the revert type could be made into an AbuseFilter variable, along with other information about the revert. This would require some kind of overhaul on the core side of things, though, see T159725.

In T262157#6439840, @Ostrzyciel wrote:

Not sure if making this feature into a separate action is a good idea. There are three types of reverts out there (undo, rollback, manual) and this would just support one of these, which is rather incomplete.

That makes sense. The problem here is that rollbacks are not treated like edits by the core code. The lack of a dedicated hook makes rollback effectively go through any AbuseFilter-like tool, e.g. the spamblacklist (and anything else expecting to catch edits via the EditFilterMergedContent hook).

I'd rather propose for AbuseFilter to somehow receive the EditResult object related to the edit, so that all kinds of reverts are treated properly. Then the revert type could be made into an AbuseFilter variable, along with other information about the revert. This would require some kind of overhaul on the core side of things, though, see T159725.

Another important point: whatever we decide to do, we should stick to that. We cannot introduce a separate action for rollbacks and then, in a few months, decide that rollbacks should be edits instead. That would be hard to do without breaking BC.

Another example: In Chinese Wikipedia there are AbuseFilter to prevent page creators from removing deletion templates and rollbacks also bypass the restriction.