Also page_age and page_recent contributors.

Change 462289 had a related patch set uploaded (by Daimona Eaytoy; owner: Daimona Eaytoy):
[mediawiki/extensions/AbuseFilter@master] [WIP] Use AsOf to compute variables for /examine

https://gerrit.wikimedia.org/r/462289

I've been too optimistic about this, but it won't be easy. To compute these variables we mostly call specific methods from other classes (the relevant ones are Title::getRestrictions and User::getEditCount|isBlocked|getRights|getEffectiveGroups). However, these methods do not provide a way to specify an "as of". This means that either:

1. There are methods I don't know of which allow passing an asof parameter
2. We add such methods to core (or change existing ones when possible)
3. We copy the content of those methods and manually add an asof (Argh! This would also require splitting user methods, which right now are all handled within user-simple-accessor)

This doesn't seem to be only a problem with editor variables, but also with page_id when a new page is created (it's 0 when the filter is triggered, but contains the actual value when the filter is reviewed at a later time). Reported originally here: Topic:V8i2gjsvwmglpiss.

In T102944#6639001, @Aklapper wrote:

The previous comments don't explain who or what (task?) exactly this task is stalled on ("If a report is waiting for further input (e.g. from its reporter or a third party) and can currently not be acted on"). Hence resetting task status, as tasks should not be stalled for unclear reasons.

Right, let me sum up. The implementation of this feature in AbuseFilter is currently impossible because MW core doesn't provide a way to retrieve the values of certain variables in a given moment in the past. For instance, no way to retrieve what user groups where, or whether they were blocked, or wheter a page was protected, etc. Some of these might be retrieved if we manually query the Database or some other hacks, but this should NOT be done.

What's more, some of this data cannot be retrieved with 100% accuracy at all. For instance, user groups: the only source of past groups are log entries, but this is a weak source, and not guaranteed to be stable.

Long story short, I'm fairly confident that it will never be possible to implement this feature for all variables. At most, we might determine which variables can be computed for a past timestamp and limit the scope to those.

Eh, thanks a lot for elaborating! (My previous action wasn't a reply to previous actions; I was more after looking at some older tickets stalled for years).
Meh, sounds like somewhere between lowest priority and declined status then, but let's see. :-/

Change 775842 had a related patch set uploaded (by Matěj Suchánek; author: Matěj Suchánek):

[mediawiki/extensions/AbuseFilter@master] Compute use and page age relative to recent change timestamp

https://gerrit.wikimedia.org/r/775842

Change 775842 merged by jenkins-bot:

[mediawiki/extensions/AbuseFilter@master] Compute user and page age relative to recent change timestamp

https://gerrit.wikimedia.org/r/775842

Naive question - could we store the value of these variables in the AbuseFilter database at the time of the edit?

We already store some variables when a filter is triggered and an entry in the abuse log is made. But only those variables that were needed and actually computed during execution (see VariablesBlobStore.php). I think it is possible to change this and always store all variables. But remember that some variables might be expensive to compute (database access, etc.) or very large (page HTML), so the increase in CPU time or used storage could be problematic.

However, that does not concern the situation when you want to test against arbitrary changes done in the past. Because that would mean you would have to do the above for every change done to the wiki (because you may want to examine potentially any change retrospectively). And this is probably not feasible.