The following sniffs are failing and were disabled:
* MediaWiki.Usage.DeprecatedGlobalVariables.Deprecated$wgContLang
Change-Id: Ic167fc5e836c5437edc6b330e5d73f9913bc2859
In both SpecialAbuseLog and ApiQueryAbuseLog, we use
Title::getUserPermissionsErrors to check if the user is allowed to
perform 'abusefilter-log' on the API page... However, this is a
completely redundant check (which is also pretty expensive and queries
the master): for the SpecialPage, we can specify the required right in
the constructor and use checkPermissions, and for the API we can simply use checkUserRightsAny.
If I'm not mistaken, there's no benefit in using
getUserPermissionsErrors.
Change-Id: I4c4dbace67b24cc1f45e50ab1c0d251522935513
We do not validate the param, and instead only check if it was
specified. In the specific case of ViewHistory, specifying as "filter"
something invalid for a title (e.g. with a + inside) will throw an
exception, seen in production.
Change-Id: I636b4e56f39282593c737ace1d6ff2d90900d997
The case default was recently added, but didn't take into account that
"false" is valid too. Noticed by chance just before the train rolled
out.
Change-Id: I67ca475fa16ea449820f8c735531c2cc1b0ec975
Now that Parser errors are on logstash, I noticed a huge spike of errors
on Wikimedia Commons, about 35000 per hour. They seem to be due to 2
broken filters, but id doesn't say which ones.
Change-Id: I8510319c075520f9a893cd7d56f2e30679e249ba
This makes the code easier to maintain and more flexible, plus adds
several tests. Some flaky tests are also improved.
Depends-On: I57ce67c5202c8574fcf1957999a6999fec264cb7
Change-Id: Ibb5322bca93b464e9014b53644c04f2bc1141e72
We just passed the description as a parameter, but it's much quicker to
use it as the key in the data provider: PHPUnit will automatically
display it in case of failure, so that we don't have to do that
manually (and still get messages like "failed with data set #7").
Depends-On: I8edcca17ecdcf71397cc9b0d101e8b13ac112047
Change-Id: I57ce67c5202c8574fcf1957999a6999fec264cb7
Tagging doesn't work for account creations, and probably never did. This
is because we used a wrong identifier for such actions. This patch fixes
the problem, although in the long term we should find a smarter way to
apply tags.
Also, clean AbuseFilter::$tagsToSet if the action will be prevented.
Depends-On: Ia8e38ba25d1989fe71714d2b76891c4587921466
Change-Id: I8edcca17ecdcf71397cc9b0d101e8b13ac112047
This may solve several issues, see T176291#4105438 for further details.
Bug: T191430
Bug: T176291
Depends-On: Iebbdeac7898b35beea79aa3d0cdf9d0fb265d726
Change-Id: Ia8e38ba25d1989fe71714d2b76891c4587921466
When updating the abuse_filter_history table, the sequence to use is the
one on afh_id... And we were using the af_id one since 2009.
Change-Id: I3e291c780119d74be5f47e745a8de13bda85486b
Instead of adding a message, do like core does by striking and greying
out the row. Plus, don't show the AbuseLog page description when hiding
entries, as it doesn't fit.
Change-Id: I645a89dd8df79d45ca440e0ba62adcdee921b8e9
Starting from PHP 7.3, passing the name of an undefined variable to compact() raises a notice. Always define $querypattern and $searchmode, so that this won't happen, and makes showList behave more uniformly.
Bug: T214269
Change-Id: Ib179a7e0e4fdd7b9d81b6930000203478e7a1e38
Right now, we allow empty messages, and when the "warn" action is
executed we use "abusefilter-warning" if no message is specified.
However, this also produces a PHP notice while editing a filter with
empty message (see Phab). With this patch, empty messages will be
rejected, and a follow-up will be discussed on Phab.
Update: added disallow message as follow-up of
Ic1de03a6944c43a346fa317ee0a217551f0d284a.
Bug: T203353
Depends-On: I8df247f61d9f3769e9580544f324dd174811e939
Change-Id: I71b1f81d10c02de4de141b1ab9b630d05cf4619c
