As reverts is made to revert vandalism, I'm asking for an optional option to make revertions to ignore bot edits, both if an bot has made an edit in between the vandal edits, and also if a bot has made edits after vandal edit.
Version: unspecified
Severity: enhancement
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | Feature | None | T16211 Revert option to ignore bots | ||
| Open | Feature | None | T13181 Mark bot edits in histories |
Recommending WONTFIX.
What rollback does is basically just pick an old revision to revert to, grab the text of that revision and save it (it probably should duplicate text_id's here, I'm not aware that it does), making it a much more efficient version of undo. If you want anything more sophisticated than that, use the undo feature or build the new revision text yourself.
(In reply to comment #1)
Recommending WONTFIX.
What rollback does is basically just pick an old revision to revert to, grab
the text of that revision and save it (it probably should duplicate text_id's
here, I'm not aware that it does), making it a much more efficient version of
undo. If you want anything more sophisticated than that, use the undo feature
or build the new revision text yourself.
Oops, big misunderstanding here, recommendation revoked.
I was under the impression the reporter wanted to revert vandal edits but not bot edits in between, while he really just wants to adjust the query we use to find out which revision to revert to, which would be a simple rc_bot = 0. The effect would be that
Vandal edit
Vandal edit
Bot edit*
Vandal edit
Benign edit**
Currently, rollback will roll this back to revision *, the proposal is to have it rollback to ** instead. Could also be implemented as an 'ignorebots' parameter to action=rollback (both for index.php and api.php), so we can either display two rollback links or have a user preference.
I wanted to write up a quick patch for this when I discovered the revision table doesn't have a rev_bot field. To filter bot edits, we'd have to JOIN against the recentchanges table, which means we'll never know whether a certain edit was a bot edit if it was made longer than $wgMaxAge ago. In the most common usecase (SineBot signing vandalism) that shouldn't be a problem, though, but this feature will still be impossible to implement completely reliably (i.e. in some cases it can be hard to predict offhand which revision "rollback ignoring bots" will revert to) unless we do a schema change.