Page MenuHomePhabricator

AF action to temporarily enable pending changes
Open, MediumPublic


The idea of deferring suspect edits for review has been suggested and found support on several occasions. The AbuseFilter provides a way to check edits and FlaggedRevs a way to review revisions, it seems sensible to combine in some way those two extensions for that purpose.
In the linked page, I suggest that a new AF action be created: to enable pending changes on an article where an edit triggers the filter, before the edit is saved, so that the edit will be marked for review (the prior revision being reviewed automatically).
The problem is that we want this to be temporary, a way to achieve this is by automatically removing pending changes as soon as the last page revision is reviewed. If possible it could be removed only after a brief cooldown period following the review, that could be fixed maybe per filter (to fend off repeated vandalism attempts).
In order to inform reviewers, it may be good to display by default the PC config log when reviewing pages, considering it's not particularly obtrusive. The AF would log the action with a link to the triggered filter and its name, but wouldn't edit the page.
For now, I think we can consider AF enabling only level 1 PC protection (autoconfirmed users are autoreviewed), to avoid complications on pages already on PC level 1 since the AF would have to restore the original setting.
I'm sure this would gain consensus on en.wp if this or a similar implementation is possible.


Event Timeline

bzimport raised the priority of this task from to Lowest.Nov 22 2014, 2:03 AM
bzimport added a project: AbuseFilter.
bzimport set Reference to bz49770.
bzimport added a subscriber: Unknown Object (MLST).
Cenarium raised the priority of this task from Lowest to Medium.Nov 15 2015, 9:15 PM

Change 218270 had a related patch set uploaded (by Cenarium):
Pass extra params to addTags function

Change 218270 abandoned by Cenarium:
Pass RecentChange to addTags function

This is no longer needed since AbuseFilter now uses RecentChange::addTags.

Update: the current implementation uses change tags as intermediaries: AbuseFilter (or any other extension) tags, then FlaggedRevs checks with the ChangeTagsUpdate hook if any of the tags is a "problem tag" (defined by tag managers), and if it is, defers. So there's no need for an AbuseFilter commit - only needed are the ones to core and FlaggedRevs.

Update: I've now added full fledged AF actions, though directly in FlaggedRevs thanks to the custom actions handler.

Update: I've now added full fledged AF actions, though directly in FlaggedRevs thanks to the custom actions handler.

Can this task be closed as resolved then?

@Cenarium: I am resetting the assignee of this task because there has not been progress lately (please correct me if I am wrong!). Resetting the assignee avoids the impression that somebody is already working on this task. It also allows others to potentially work towards fixing this task. Please claim this task again when you plan to work on it (via Add Action...Assign / Claim in the dropdown menu) - it would be welcome. Thanks for your understanding!

Proc removed Proc as the assignee of this task.Jun 15 2020, 4:52 PM

AbuseFilter has already provided a good API for this: Extensions can create their extension of the MediaWiki\Extension\AbuseFilter\Consequences\Consequence\Consequence class and register it using the AbuseFilterCustomActions hook.
In theory, this could finally be very close to being implemented.