Follows-up I5a5420df13893386.
> We lose useful coverage and waste valuable time on keeping tags
> accurate through refactors (or worse, forget to do so).
>
> Tracking tiny per-method details wastes time in realizing (and
> fixing) when people inevitably don't keep them in sync, and time
> lost in finding uncovered code to write tests to realize it was
> already covered but "not yet claimed".
>
> Given all used methods are de-facto and liberally claimed, and
> that we keep the coverage limited to the subject class, this
> maintains the spirit and intent. PHPUnit offers a more precise
> tool when you need it (i.e. when testing legacy monster classes),
> but for well-written code, the class-wide tag suffices.
Ref https://gerrit.wikimedia.org/r/q/owner:Krinkle+is:merged+message:Widen
Change-Id: If7304d8b5b43ab8a051fbcecced331a787bab960
It is a common pattern to avoid SELECT * and use the fields used by
the application to avoid loading to much data into memory and maybe use
performance benefits when fields are covered by index.
Change-Id: I08a399f1b6a66442317b151be5386c9d2485f1fb
> We lose useful coverage and waste valuable time on keeping tags
> accurate through refactors (or worse, forget to do so).
>
> Tracking tiny per-method details wastes time in realizing (and
> fixing) when people inevitably don't keep them in sync, and time
> lost in finding uncovered code to write tests to realize it was
> already covered but "not yet claimed".
>
> Given all used methods are de-facto and liberally claimed, and
> that we keep the coverage limited to the subject class, this
> maintains the spirit and intent. PHPUnit offers a more precise
> tool when you need it (i.e. when testing legacy monster classes),
> but for well-written code, the class-wide tag suffices.
Ref https://gerrit.wikimedia.org/r/q/owner:Krinkle+is:merged+message:Widen
Change-Id: I5a5420df1389338644a099ebfd072063653e6849
Constructing a Status like this does not make sense (and I want
to deprecate it in I0675e557bb93a1c990fa923c50b9f6ee8a9836c8),
because the parameters are ignored by most Status methods:
$error = Message::newFromSpecifier( 'abusefilter-blocked-domains-attempted' );
$status = Status::newFatal( $error, 'blockeddomain', 'blockeddomain' );
But it worked here, because FilteredActionsHandler::getApiStatus()
used a deprecated method that allowed inspecting them.
I feel like this code in BlockedDomainFilter has been added to make
the tests pass without thinking about what it actually does, which is
to output a bunch of useless incorrect data in API errors.
I'm not sure if we can remove that now without breaking API
compatibility, so add the useless data in FilteredActionsHandler
instead, closer to where it's output.
Change-Id: Ic12241bd3029bc1b0e7a0023689a2be35ccd30a8
From Status class documentation:
> The recommended pattern for Status objects is to return a Status object
> unconditionally, i.e. both on success and on failure -- so that the
> developer of the calling code is reminded that the function can fail, and
> so that a lack of error-handling will be explicit.
Change-Id: Ie6a55e297a35374fbdef880dd40e65f5cd00b6bf
The static method has already been migrated.
Also rewrite the test cases to avoid non-static provider (T337144).
Change-Id: Ibf98539f442e1ba8a9e9eb510784d40778123f17
MessageLocalizer::msg( $key, ...$params ) accepts a variable number
of arguments, but getMockMessage does not. Passing only the first
argument as a string to getMockMessage is not supported.
Required for I86ff2d6.
Change-Id: I30ab799ceab36b80c330d1233f3009814d7f6c98
It does the same and is well supported in the PHP versions we
currently use, at least when the arrays contain integer keys.
Change-Id: Id038142621dab47bfc03db48ce676ed0b2cdc28b
MediaWiki core change Icb8822def9ce56f42ff52a8e469bb08d61d576c6
improved the type hints for OutputPage::addWikiMsg(), resulting in
two new errors:
* AbuseFilterViewEdit.php: False positive, update suppression
to include new error code.
* SpecialAbuseLog.php: Genuine bug, the return value of
Status::getErrors() can't be used directly as a message key.
I have another change pending that introduces a nicer way
to do this: Ibc4ce11594cf36ce7b2495d2636ee080d3443b04,
but in the meantime, make do with the available getters.
Change-Id: Iee0e87496e27a5261adccb977361b3ccf4c9ee2c
InsertQueryBuilder does not ignore insert of no rows,
adding some conditions to avoid calling the query builder
Change-Id: I1752b90cc3a7ec3a7f9ee32a1873bf8c82b6e02e
Introduced in 2019 with 4c8dac4dc6. Redundant since 2020 with
commit c6c62e2c8f in MediaWiki core.
Bug: T139216
Change-Id: I51e9fc3899cf5505917d7899a395350dd86f5c0b
Make the order of the messages that describe
operators and functions in the en.json file
identical to their order in
KeywordManager::BUILDER_VALUES, which is also
their order in the actual UI of the filter editor.
This only reorders the mesages in the en.json file.
It's not supposed to change anything in
the end users' experience, but it will change
the order in which translators on translatewiki.net
see them.
This is a cleanup step towards removing
the explicit operators from the messages,
as suggested in T360909, and this reordering
is hopefully useful even without that change,
for general consistency.
Comments about particular messages:
* abusefilter-edit-builder-vars-timestamp-expanded
is moved to the very end because, despite its key,
it's not actually used in the filter builder.
* old-text, old-html, and minor-edit are moved towards
the end because they are outdated. They are listed
separately from BUILDER_VALUES and they are not used
in the filter builder UI, but they are used in the logs
of previous actions. This patch adds a code comment
for the benefit of developers who touch that code
in the future.
Bug: T360909
Change-Id: I86ecdca5a6173b9068d5e968e69c57c74a379888
