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
A filter using a protected variable can be loaded via filter id
using testing tools even though the user might not have the right
to view protected variables. This can potentially leak PII and as
such, testing tools should check for the right before allowing
protected filters to be seen.
- Unload a filter asap if it uses protected variables and the
requestor doesn't have viewing rights. This:
+ disallows loading of existing protected filters on page load
+ disallows testing against rules that use protected variables
+ disallows subsequent requests for protected filters (via API)
There is a known bug (see T369620) where no user feedback is
provided if an API request for a filter returns no result (typically
when no filter matches the requested id). This commit adds another
pathway to that bug (the filter exists but is protected and not
returned by the API) but does not update this UI/UX.
Bug: T364834
Change-Id: I6a572790edd743596d70c9c4a2ee52b4561e25f3
Why:
- Ie13181b78b8e2903c6cc0f0f778689bcc8b8ce2e modifies the status message
returned
What:
- Loosen the check for the status error message such that 'captcha-edit'
and 'captcha-edit-fail' are both valid; we can revert this after
Ie13181b78b8e2903c6cc0f0f778689bcc8b8ce2e is merged
Change-Id: I5a0698d84932a474800a68dba9b76b3433b19290
Why:
- These checks are no longer needed, now that Idc47bda has been merged
What:
- Remove the `method_exists()` checks
Change-Id: I6e428df6b6e036146ae4cc57374cde8810d3f5f7
