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
*Don't reuse a message (which is bad), instead add a note for
translators. We can also move it on translatewiki.
*Don't show the AbuseLog link if the user cannot see the AbuseLog.
Change-Id: I4ce73b2160275fdc4b0b7bec722471696d8c6a4d
As follow-up of I10b1fd2d9bdfe518089c053d77fef568170ecb65, use
'AbuseFilter' instead of 'AbuseFilterDeprecatedVars' as channel name.
Raise level for null-title filtering. Since with a null title
several things are likely to break, a warning is more appropriate here.
Tweaked the message as well, to include the bug number and to avoid
pointlessly including the title (which is null).
Lower the level for stashedit hit/miss (as it's really spammy and not
that useful right now).
Use 'abusefilter' instead of 'AbuseFilter' for statsd so that everything
has the same prefix.
Also raise the level for parser exceptions and unrecognized
consequences.
Change-Id: I1f9988155e924232b201281795cd322636da8082
Follow up to Idbb3a70d08a195dfa21422e07f593d1eeba4521d
This also fixes the fetching of text for the stash edit code path
which was missed by the previous patch.
This now also uses the full old text in the variable holder.
Bug: T213453
Change-Id: Ib80bc6385ebb5dd82bb1a384dd0e162608bfcbfa
