Adds AttributeManager to EchoServices so that dependencies of
AttributeManager can be injected.
Bug: T275148
Change-Id: I4fa5084d72914d16b6d218e7dd3521f5a1919b80
The following sniffs are failing and were disabled:
* MediaWiki.Commenting.FunctionComment.MissingDocumentationPrivate
* MediaWiki.Commenting.FunctionComment.MissingReturn
* MediaWiki.Usage.ForbiddenFunctions.isset
* MediaWiki.Usage.PHPUnitDeprecatedMethods.AssertInternalTypeGeneric
Additional changes:
* Also sorted "composer fix" command to run phpcbf last.
Change-Id: I29416247ff3736799543926813beaf4afd569a6e
assertEquals() does not compare the type. It can not only be a float,
it can even be a string. E.g. 9 and '9' are considered equal.
Worst case scenarios are:
* 0 is considered equal to any "falsy" value, including the empty
string.
* 1 is considered equal to true.
assertSame() does not have any of these confusing edge-cases.
Change-Id: Ib6af0fefbbd8856adcf27844bb8ddd8e33ed3f9d
Not all tools require these to be absolute, full qualified class
names. But some do. This does make the code more compatible with all
kinds of tools.
Change-Id: Ie7f9d9469b7a48b2fe908d3428fca9ec0120f855
PHP doesn't care much about the name (in terms of case sensitivity)
but I think we should make sure the names of the method should be as
they're in their definition.
Change-Id: I6e38d8be64efaec4200471f2d3007275d7ddecec
It was sort of checked in an implicit and roundabout way, in the sense
that the preferences page checks this and forces the relevant
preferences to on or off. But this was difficult to discover, and it's
not clear if this works correctly when defaults change.
Instead, explicitly check whether the requested notify type is available
for the event's category. Also rewrite the entire method to use
array_filter().
Change-Id: I9502a42fc705b2e56ef5edab433f1804f2924359
The codebase already used the …::class feature in many places. So this
is more for consistency than anything. The …::class feature makes it
much easier to do refactoring in the future.
Note this patch is exclusively touching tests. That should make it
relatively easy to review this. As long as the CI is fine with it, it
should be ok. Right? ;-)
Change-Id: I4d2adee76b4adbc83b2061161fd4e863ba833fcb
Replace getAlertEvents and getMessageEvents with
getEventsForSection.
Also, add IDs for linking to sections
Bug: T123018
Change-Id: Ic480320a52a401609d853fc8c75c781b89bb8722
Merge and deploy at the *same time* as:
* BounceHandler - I3c669945080d8e1f67880bd8a31af7f88a70904d
* mediawiki-config - I13817c139967ed9e230cfb0c87c5de66da793c96
Despite claiming to be about categories, $wgEchoDefaultNotificationTypes
was actually configuring both categories and types (which go inside
categories).
For example, 'thank-you-edit' is a type, but 'emailuser' is both
a category and a type (when used as a category, this has special
effects at Special:Preferences).
Since types and categories can and sometimes do have the same names,
this leaves no way to properly and clearly configure them. It also
makes it difficult to document what is going on (as required by
T132127).
Split into three variables:
$wgDefaultNotifyTypeAvailability - Applies unless overriden
$wgNotifyTypeAvailabilityByCategory - By category; this can be and is
displayed at Special:Preferences
$wgNotifyTypeAvailabilityByNotificationType - By type; this cannot
be displayed at Special:Preferences. To avoid confusing the user,
we introduce a restriction (which was previously followed in practice,
AFAICT) that types can only be overridden if the category is not
displayed in preferences.
Otherwise, it can look to the user like a category is on/off, but the
types within might have the opposite state.
Due to this configuration change, this is a breaking change, and needs
coordinated deployments.
This also lays the groundwork for T132127
Also change terminology to consistently use "notify type" for web/email.
It was mixing between that and output format (which unfortunately
sounds like the API format, e.g. 'model').
Bug: T132820
Bug: T132127
Change-Id: I09f39f5fc5f13f3253af9f7819bca81f1601da93
Right now, if certain users should be excluded, that would have
to be part of the user-locators already. This is annoying because
it's hard to write "generic" user locators when you want to exclude
just a couple of people in certain cases.
In Flow, for example, we have user-locators for users watching a
board or topic. We don't want to send the notification to people
that have also been mentioned in that post (they'll get a separate
notification). We could build that exception into those
user-locators, but then we couldn't re-use them in other places...
This basically means we couldn't use EchoUserLocator::locateUsersWatchingTitle,
we would have to roll our own that also excludes mentioned users.
Instead, this lets you add 'user-filters' (that functionality
actually exists already, but is not currently exposed), which
lists users to not send the notification to, even though they could
be in a user-locator.
Bug: T125428
Change-Id: Ifa0e2d3283f57624af4c5ec264f9f66223508e83
