mike.lifeguard+bugs wrote:

Indeed, making it clearer whether an edit (etc) succeeded or not would be nice. Making it abundantly clear, like in big red text or something. Maybe not flashing though.

This is annoying because the abuse log entries are inserted before revision data is, although in theory it could be added afterwards by storing the logids in a static variable of the AbuseFilter class and adding a post-save hook to populate that field (as is done for change tags).

matthew.britton wrote:

(In reply to comment #2)

This is annoying because the abuse log entries are inserted before revision
data is, although in theory it could be added afterwards by storing the logids
in a static variable of the AbuseFilter class and adding a post-save hook to
populate that field (as is done for change tags).

Ah, I was half-suspecting there might be some technical reason for it... it's not urgent in any case.

(In reply to comment #1)

Indeed, making it clearer whether an edit (etc) succeeded or not would be nice.

Agree with this, not sure how to go about it though. Big red text might be over the top.

matthew.britton wrote:

I've worked around this for my purposes (read recent changes and abuse log, match up items on username and page title, works 99% of the time) so don't worry too much about it. Would probably be considered nice to have in the UI though.

matthew.britton wrote:

Is there an intention to fix this at any point?

(In reply to comment #5)

Is there an intention to fix this at any point?

Maybe. It needs a schema change and other stuff like that, and it seems to have a limited impact.

matthew.britton wrote:

(In reply to comment #6)

(In reply to comment #5)

Is there an intention to fix this at any point?

Maybe. It needs a schema change and other stuff like that, and it seems to have
a limited impact.

Sorry, my bad, didn't know it needed a schema change.

Its impact is limited now because of the tagging system -- revisions that trip abuse filters that you want to monitor can be tagged, and then you can patrol by tag rather than by filter. Tags weren't enabled yet when I originally filed this bug, so back then it seemed a bigger problem. The other reason its impact is limited is most people don't seem to be aware of how the whole filtering/tagging system works and its potential for recent changes patrolling. That's not a problem with the software itself, of course.

I'm not insisting you fix it, just wondering what the intention was so I know what to expect (I'm torn between trying to track abuse filter hits directly or just tracking tagged changes; the latter is fine as-is, the former would need this to work "properly" and would have the advantage of being able to track anything without having to keep requesting new tags to be added, and also of tracking instances where a warning was shown but no action done).

Marking this bug as Lowest priority.

I've done this in a batch to (usually enhancement request) bugs where:

• It is not clear that this bug should be fixed.
• It is not clear how to fix this bug.
• There are difficulties or complications in fixing this bug, which are not justified by the importance of the bug.
• This is an extremely minor bug that could not be fixed in a few lines of code.

If you're interested in having one of these bugs fixed, your best bet is to write the patch yourself.

matthew.britton wrote:

(In reply to comment #8)

• It is not clear that this bug should be fixed.

It breaks the workflow of using abuse filters to assist with change patrolling. Which I *thought* was the whole point of it.

• This is an extremely minor bug that could not be fixed in a few lines of

code.

Granted it may be a large fix, but it is not 'extremely minor'.

If you're interested in having one of these bugs fixed, your best bet is to
write the patch yourself.

Yes, always the way with open source. But I didn't ask for a half-finished filtering system to go live on Wikimedia projects (in fact I strongly opposed it), so I don't quite see why it should fall to me to finish it. Anyway, if left up to me I'd do away with it altogether, so I doubt I'll be writing a patch any time soon.

• Bug 25950 has been marked as a duplicate of this bug. ***

Fix committed in r111217. Comments welcomed.