AbuseFilter handles merged edit conflicts wrongly
Closed, ResolvedPublic

Description

See, for example, http://en.wikipedia.org/w/index.php?title=Special:AbuseLog&details=593181 corresponds to http://en.wikipedia.org/w/index.php?title=Howcast&diff=296900469&oldid=296900306, and not http://en.wikipedia.org/w/index.php?title=Howcast&diff=296900469&oldid=296900379. This only happens when the times of the edits are close to each other; it was suggested that the reason for this is edit conflicts.


Version: unspecified
Severity: minor

Details

Reference
bz19324

matthew.britton wrote:

(In reply to comment #1)

Looks like the automatic resolving of edit conflicts is what is causing this.

Ugh... the abuse filter comes before even *that*? I've said here before that it should be the *final* step before an edit is saved... at the moment we get all manner of strange situations where the abuse filter is triggered where it should not be (esp. on edits that would have failed anyway, like rollbacks to non-top edits), of which this is only one.

werdna added a comment.Jul 3 2009, 2:10 PM

Updated summary.

(In reply to comment #2)

(In reply to comment #1)
> Looks like the automatic resolving of edit conflicts is what is causing this.

Ugh... the abuse filter comes before even *that*?

No, it comes after that. That's the problem.

(batch change)

Minor bugs that nevertheless need looking into

Looking at the code and testing locally indicates that this is resolved with the current SVN version. Must have been unintentionally fixed at some point.

rockmfr wrote:

This was fixed by r52740, based on my testing. Would this be an expected side-effect of that change?

Add Comment