Why:
* The SearchFilters.php maintenance script fails to produce any
filters when the --pattern option is not provided
* This is because the condition that checked for a missing pattern
did this after it was passed through ::addQuotes, which made
the value always truthy.
What:
* Fix this bug, so that the --consequence option can be provided
without the --pattern option.
Bug: T373148
Change-Id: I316d3f940a8e7616a56040077a20563ee653515b
Why:
* SearchFilters.php allows the caller to search by a regex that
is applied to the pattern.
* This script can be expanded to allow callers to specify what
consequence should be associated with the filters that are
outputted.
What:
* Add a 'consequence' option to the SearchFilters.php maintenance
script, which is applied through a LIKE query on the
af_actions column.
** This can be specified with or without the pattern option.
** Instead of making pattern required, the script now requires
that one of consequence or pattern is provided.
* Expand the tests for the script for this new code, along with
using the new ::expectCallToFatalError method to be able to
test previously untestable code.
Bug: T373148
Change-Id: I1b507d8f9dc1f4cf91ee4f83ccde745eb6d46d6d
Make the `reason` parameter default to the empty string, so that we
don't end up passing null to ManualLogEntry::setComment.
Bug: T373010
Change-Id: Ifca828401628368bdddae14df2bbeb7391b2c02d
get_debug_type() does the same thing but better (spelling type names
in the same way as in type declarations, and including names of
object classes and resource types). It was added in PHP 8, but the
symfony/polyfill-php80 package provides it while we still support 7.4.
Also remove uses of get_class() where the new method already provides
the same information.
For reference:
https://www.php.net/manual/en/function.get-debug-type.phphttps://www.php.net/manual/en/function.gettype.php
Change-Id: I5e65a0759df7fa0c10bfa26ebc3cda436630f456
Per discussion, as a compromise (that I’m fine with), I’m leaving these IDs localized (i.e. the digits may be other than arabic), and I’m only removing the thousands separators.
Bug: T348717
Change-Id: I77b484fec2071267c53a139104c23755a13f0129
This uses Codex provided colors in AbuseFilter primarily to
make it compatible some parts such as the log table with
the dark mode.
This however doesn't touch Ace highlight customisation of
the extension as Ace itself isn't dark mode compatible yet
the far I know.
It treats one #aaa color for borders the same as #a2a9b1
and uses a darker text color for deleted vs disabled
unlike what was before as I tried to both make it distinguishable
but use @color-disabled for that disabled style.
Change-Id: Ifddbda378754260ca8d8802bfd8c6c98de8e1def
In my recent change c458651370, which used Status::getMessages()
in FilteredActionsHandler, I overlooked the fact that it returns
MessageSpecifier objects instead of Message objects, and the return
value of MessageSpecifier::getParams() is not exactly specified
(the docs only promise that it's an array).
Now I'm working on a MediaWiki core change (I625a48a6ec) that
causes a different MessageSpecifier to be used, which stores
parameters in a different format, and would break that code.
To avoid problems, ConsequencesExecutor now stores Message objects
in the Status, which guarantees that FilteredActionsHandler will
get the same objects back.
Change-Id: I2c1bc8dde9a078d03badecf6d89443b65eeb92c5
