Following up I636b4e56f39282593c737ace1d6ff2d90900d997, enforce a basic
clientside validation and don't fill the field with the URL parameter if
it's not valid.
Change-Id: If4fd015dff64237375a0c4d3b9fbcefbd54dba3e
Some ObjectCache:: methods are soft deprecated since 1.28. Remove them
now, since the replacement is easy.
Change-Id: I713781d5e98238a1c194e97b5faae488a8ac190d
Using break could halt parsing between operations, instead use continue
to parse all operations.
Bug: T214642
Change-Id: If67ddaffef280c2448c55ae536013758617bba68
This adds the capability to filter AbuseLog using filter groups, if
there's at list an extra group (like flow). Since abuse_filter_log
doesn't store info about filter groups, this needs query on
abuse_filter, and its result must then be intersected with explicitly
searched filters, if any.
The way I wrote it takes several lines and IFs, but is meant to be less
subject to regression in case something gets moved.
Change-Id: I747ba491d2b390562ce5f71396eed095116d8eaf
For wgLang, there's a Language object available in the proximity, so just pass it.
For wgContLang, use MediaWikiServices.
Change-Id: Ic492007f2d5eeb8048d0919a4b9b7dd98c15c350
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
Several people have reported throttle groups being hard to use, mostly
because the field doesn't have options with the usable groups. This is
because users can combine valid groups in many ways, and thus we don't
provide options. However, let's add an help link pointing to mw.org.
Change-Id: I982d67aa62a899916a26452aceb9646df8c31232
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
Another batch of changes for the throttle script, fixing bugs discovered
on its last run and improving performance.
For a list of fixes, see T209565#4903044.
After merging, we need backports (REL1_32 and wmf branches) and another
dry-run.
Bug: T209565
Change-Id: I530a22d57971f8b22892e43faae5d1c6fa1e14ed
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
This is an old leftover, used to add global JS variables in a convoluted
way: using a hook and a total of 3 static properties. We can safely
remove all of this and just call OutputPage::addJsConfigVars, which BTW
is already called where we need it.
Change-Id: Ifad0618fa93b0c7a7e8b23f596234e622aa8846a
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
