When all the other patches will be merged, this workaround won't be
necessary, and by removing it we're finishing the first phase of
variables migration. Which could also be the only one if we decide not
to go on and remove the old ones.
Bug: T173889
Depends-On: I5c370b54e6516889624088e27928ad3a1f48a821
Depends-On: I6576497feaf6d2c475ee33a91feb6a640e2c20fe
Depends-On: I87a48fdc8b392b25eb02807e8d0f712d0a399ece
Depends-On: Ib29eb15c1a51c037d036be8dc1541d96ea4b174b
Depends-On: I909a99e80a895a9b009c33ea72e8e0a4ea0a1375
Change-Id: If5f238cddb41ef92b141e36b4f2f15fd4cc86476
This is for adding variables which can be computed even without an
ongoing action. Currently, we don't have any, except for timestamp (but
that's a bit special). Other extensions could. For instance, we'll be
able to expose the content of the spam blacklist.
Bug: T211680
Change-Id: Iba59fe8d190dd338ecc8cfd682205bce33c9738b
It's totally pointless to recreate all variable names, since we already
have them in builderValues. The only exception is for _restrictions
variables, although they should be handled in builderValues too.
Change-Id: I156ebb1e6e590d09ded093a23d19c0d635a503bf
Otherwise calling bufferTagsToSetByAction multiple times makes the list
grow, and IIRC the core doesn't call array_unique on the tags to apply.
Also clean the list after applying tags.
Change-Id: Iebbdeac7898b35beea79aa3d0cdf9d0fb265d726
The variable was disabled with I7f13773766e12f3d4b86451fdf3ae23e067ac373
in 2016, but not in the same way as old_text and old_html were disabled
in 2009. This patch uses the methods introduced with
Ife168522e6b1d8eb94ebbb8a16ae8831ec1dc497 to disable minor_edit in a
standard way, so that it won't be showed in new AbuseLog entries, and
won't be usable when writing filter syntax.
A warning will be emitted if a pre-existing filter is using it, so that
we'll be able to completely disable it in the future.
Change-Id: I5ad5219ee19a5e6ba2bfdffb4e0aad63c8951491
This ensures that each repository's "npm test" command is fully
independent of wherever it might be in the filesystem.
Bug: T206485
Change-Id: I4b9598d41b2fe01703b89914f9c1a470ed1a9cf2
Instead of only the first one. This is quite hacky, but I don't have
much time right now, and this script is written in the spirit of JFDI.
Bug: T209565
Change-Id: Ic12ff21dd41b619bea9c71001555fd4d6299e58b
In T209565#4826952 I discovered that if the "abusefilter-blocker"
message is an invalid username, we silently end up without a system
user, thus risking to break something. Instead of silently failing, emit
a warning and use the default name. As I wrote in the code comment, we'd
better avoid throwing, because the message can be modified by anyone,
who could then break the site.
Change-Id: Ifa866bd9676945bf94e7e481adf6ad0d6cf4370c
This partly reverts If72b18bedac5e580487406e696aea1fd172ae45b. While
it's true that we don't need every filter, that method is public and
other code may need fields that we don't need. This way we can encourage the
use of this function (which caches the result) instead of direct DB
access.
Also, the method can currently accept global filters passed as
"global-<integer>", but saves them to cache with the same key as local
filters (i.e. local filter 15 and external global filter "global-15" are
both saved in AbuseFilter::$filterCache[15], which could lead to subtle
bug).
Change-Id: Ieb04f019453033c275e211cfc9fd68d5d7c392ef
My final testing unveiled 4 problems, see T209565#4780868. Testing again
after this patch yields the expected outcome.
Update: A fifth problem is that we cannot disable throttling if throttle
groups are empty or fully invalid: that case is similar to the one with
invalid rate, the throttle limit is never reached and thus throttle just
doesn't work. Instead, ask users to fix it by hand.
Bug: T203336
Bug: T209565
Change-Id: Id03c9880f60764efc596ac40b8662087fdb30550
We have two situations where we try to execute filters without a title.
However, the code doesn't handle it correctly: some points expect $title
to actually be a Title object, and we also pass it around using a hook
which explicitly says it always pass a Title. This patch adds two debug
points to help understand why we end up with null titles, so that we can
fix it upstream.
Bug: T144265
Change-Id: I35bfc483a0c69a5cbd38eae8ba299189955fa1ec
Currently it barely has any reason to exist, as it's a single-line
method. This patch moves there the global state, and also changes the
signature to allow shorter calls.
Change-Id: I7851fa41cbd96912b3859319ba97a501b1cbaa57
AbuseFilter::buildFilterLoader is only used in ViewExamine and
ViewTestBatch, so this patch moves it to AbuseFilterView and makes it
non-static.
Change-Id: I7f11cfd7ac81e536492eb59c40da7c14771cee2b
This is a first step towards MCR support in AbuseFilter. The textual
representation of all slots is concatenated. Since AbuseFilter uses
getTextForSearchIndex to determine the textual representation of
content, blind concatenation should not break any assumptions
made by AbsueFilter rules: this naive approach is no worse than
AbuseFilters handling of non-textual content in general, and should
work fine for textual content.
Bug: T209291
Change-Id: Ic141085cad2e11bfe106fe83dafcb35ac31206ba
For several reasons:
*We're not really checking permissions (and the hook previously used is
meant to be used in such case)
*We'll show a cleaner error message (i.e. without the "You do not have
permission..." part)
*Filtering will happen closer to the actual move
Bug: T208907
Depends-On: I4733724075b7514e9db59e7be772d9409aa9da87
Change-Id: If88f736a446247f8b4b13c055c641d56f544d1ea
While editing filters, sometimes it happen that you make some change,
forget about it and then reload/close the page, and no warnings will be
issued. This patch makes use of the core module used for normal page
editing to display a warning if trying to leave a filter editing page
with any unsaved change (both to the filter pattern or other form
elements).
Change-Id: I78d79215565d5c82028b1a2a4276497ccbffdea2
Later, we will add a new POST request which will allow retrieving
the private details; it will have a mandatory "reason" parameter,
and will result in a log entry in the private details access log,
just like the web interface.
Bug: T210329
Change-Id: Iaca492371f48fecf543268c179a651841ed12c3f
Signed-off-by: sbassett <sbassett@wikimedia.org>
Those two global config variables were removed more than 2 years ago, in
I790d39c2849922d7daf7479f298cd90cf30af129. Nothing else in the code
references them, so we can just remove the warning.
Change-Id: I427d06a80131447ea64064f45e84349f93e72cca
This is a follow-up to Ic3bc6e36506973b19a9b1bcecbc1a5080faed2ec. I
believe it's important to specify how many recent actions we're looking
at, and I also think it's not nice to rely on a variable amount of
actions to determine whether a filter should be throttled. Also, require
a $group parameter in filterUsedKey (we always pass one, and there's no
reason not to).
Change-Id: I0384d3f1913ead593f605248950606c81c8f8542
