* This is very slow as there can easily be hundreds of filters,
each doing 6 memcached queries. Xenon flamegraphs show a lot
of time spent in this method, slowing down editing.
Change-Id: I31e4502bbd45cc284db3cd89eb34ad365c59905b
* Also removed some code duplication
* Use getConnectionRef in checkAllFilters so that the
DB connection can be reused
Bug: T93141
Change-Id: I17c5a976b6c45029cde4ed34ad82d69e365ae8c5
When importing filters, the code is using the magic value
of 'new' for the af_id field, which is of type bigint, to
indicate a not-yet-inserted record.
In MySQL, comparing a bigint to 'new' is legal but always false,
while in PostgreSQL it is illegal, and led to errors when checking
if the filter is hidden.
Fix this by adding special-case code to filterHidden so that it
always returns false for 'new' records. In PostgreSQL this fixes
the error, and in MySQL it avoids a pointless trip to the database.
Should be back patched to 1.23 and 1.24
Bug: T89514
Change-Id: Ib4b5585ac9889a1760ec930c555e7809a424538e
Allows for more broad filters to check for a given right, rather
than having to check against multiple groups, which becomes useful
with global groups.
Bug: 60191
Change-Id: I95b5477d6d868d4b83bcd98e779e6d535aa755b3
If multiple filters all add tags to an edit, make all of them be added
rather than just one of them.
Bug: 66387
Change-Id: Ib666c2765718d7d0603921ab94d22a7d51cbd3d2
* Due to the nature of this code (a throttle) it will likely slam the DB,
so push it after the end of the main transaction.
bug: 60600
Change-Id: I48895358deaa1b951d849eeee14c7126cfa25ec8
The text areas for the table row had only 5 rows, which is a lot less than
the default number of rows.So now the number of rows in the testing textarea is changed to 15.
Bug: 59869
Change-Id: I9f221e7a49473ae1d473333f7ecf26235366d257
I'm not really sure why it exists; I assume to minimize overhead of init'ing
multiple AbuseFilterParser objects that would be exactly the same.
However, checkConditions() - which checks one specific condition - is not really
an "endpoint" you will want to call in <your-extension-that-uses-AbuseFilter>.
You're more likely to call something higher-lever (like
AbuseFilter::filterAction, which will take care of fetching all appropriate
filters, as well as run them through checkConditions, and much more). This will
trickle down to ::checkAllFilter, down to ::checkFilter, which would eventually
call ::checkConditions with the 'keepvars' argument.
Basically, unless you're re-implementing much of AbuseFilter yourself, you won't
get to pass anything other than 'keepvars' to checkFilter.
As a result, even though you may call AbuseFilter to call on multiple different
vars, it will re-use the same parser with the first vars.
I'm proposing to drop the 'keepvars' and just keep the vars around instead.
checkFilter can compare previous vars with new vars, and only init a new Parser
if the vars are different.
Change-Id: I96ccc60c77f3cdbb82c0f9f16782a1a44ffb1592
...otherwise it doesn't work.
This change add 2 checks for object caching, one for the filter
configuration interface, and one for the actual throttle checking.
Bug: 50894
Change-Id: I89ebcc6ff7d91d3a9ad8e744c0c4ff3e33e3b673
If AbuseFilter::filterAction changed $wgTitle, we need to reset it back
to the old value before returning.
And for good measure, we also need to check the main RequestContext to
make sure it didn't cache the bogus $wgTitle on us.
Bug: 53498
Change-Id: I4d706a1ee07f0b171f98e7d558d7be27e6759614
AbuseFilter::getConsequencesForFilters uses filter ids as
array keys, that causes problems if both local and global
filters were hit, because array_merge reindexes arrays.
Example:
https://www.mediawiki.org/wiki/Special:AbuseLog/18687
Change-Id: I81cb110322461e30113199cfa313cd8e8e8b2262
