(bug 28633) With $wgUseAutomaticEditSummaries=true, the edit summary is
different between EditFilterMerged and ArticleSaveComplete. AbuseFilter
was using edit summary changes to attempt to detect whether the two
hooks refer to the same edit. If it really is possible for multiple
edits to be performed in the same request, with arbitrary patterns of
EditFilterMerged and ArticleSaveComplete calls, then some more robust
method would be needed to match the hook calls. But I don't think that
is necessary at present.
Change-Id: I94321905f38eafde8add00eff73745af255c1f15
Currently it checks if the filter is set to hidden, and then
requires the private permission to view it, which is intended
for private data (like IP addresses), not hidden filters.
Change-Id: Iff8f9edf2466050aeadf3907dcff5464e179ff68
I've changed the JS of the AbuseFilter extension to match our
coding conventions and made it use mediaWiki.Api(). Furthermore
I fixed several error handlers and made some things nicer in
general while trying to not change the user appearance.
I've tested the changes as good as I could (I'm pretty sure everything
works).
Change-Id: Iaa0f99367bd7e0bfaf7249dcc9ac9ce9881b46e1
AF is setting several lazy load variables for the currently editing user.
To do this it's passing along the user name extracted from a user object
and generating a new user object later from that name which is of course
pointless. With this patch I'll pass user objects directly to prevent that.
On top of that I've deprecated a method in AFComputedVariable::compute which
was redundant as there is a more generic one which can solve that task
just fine.
Furthermore I've changed the logging behaviour from serializing the whole
AbuseFilterVariableHolder object to only store the variables. That has two
major advantages:
* The amount of data that needs to be saved on a filter hit is reduced
to about 1/10 of what the old version needed.
* This is much more forward compatible as the old way of saving this
relied on the class structure to stay the same while this is a simple
array containing the vars.
On top of that we now only log variables already set by the time
a filter is hit. On top of the obvious performance increasement
that makes it easier for the user to spot the relevant data.
Another thing this change alters is the way the AbuseFilter internally
works with AbuseFilterVariableHolder objects. Right now we use one for
testing the filter(s) and later we use another one to compute the same
data again in case a filter was hit (for logging)!
This is not thoroughly tested yet, but way more sane than what we're
currently doing!
Change-Id: Ib15e7501bff32a54afe2d103ef5aedb950e58ef6
