Tagging recreations of deleted pages would be a useful filter as patrollers have no easy way of noticing when that happens, but currently AbuseFilter does not support that. It would be nice if it had e.g. a variable for the number of deleted revisions.
|mediawiki/extensions/AbuseFilter : master||AbuseFilter: Add variable showing number of past deletions|
|mediawiki/extensions/AbuseFilter : master||Add ability to detect deleted revisions|
|Open||Huji||T22892 Add ability to detect deleted revisions and page creation|
|Open||None||T68961 Logging needs an index to optimize searching by log_title|
I think the "number" of deleted revisions is not something that should be exposed publicly (only sysops can see them outside the AbuseFilter, so only sysops can also see their count in the AbuseFilter's context). On the otherhand, the fact that the page was deleted (which is publicly available in logs) is something that can be also useful for AbuseFilter purposes. Hence my recommendation for a "has_been_deleted" variable in bug 66031.
Gerrit change 139103 has CR -2 now because there's no index to quickly get the number of times it has been deleted.
I was going to propose a variable with the number of deleted revisions, but I'm a bit shocked because the archive table has index for ar_namespace but not for ar_title (!!!) , so it will have the same problem. But because of that, does it mean that the message that appears on top of pages that have deleted revisions is using a slow query to get the number of deleted revisions, because there's no index for that? I guess there should be an index for this one (namespace and title).
I believe the lack of index is a separate bug. Since we already have a functionality in MediaWiki itself that is using a non-indexed column to show a message to the user when trying to recreate a previously deleted page, one might say that having a similar functionality in AbuseFilter should not be prohibited just based on the lack of index. Regardless, I've created bug 66961 as a blocker, and will wait for that to be fixed before my patch for 20892 is implemented.
In the meantime, I would be grateful if one could review the latest patch to see if there are any *other* problems with it.