Commit graph

14 commits

Author SHA1 Message Date
jgiannelos 4f4786c62c Avoid enqueueing delayed jobs if not supported.
Change-Id: Ibb065f77a67bf47daafb6caaf8a338d0bcd479e7
2020-11-02 16:06:09 +01:00
jgiannelos c97b8e6851 Implement delayed echo notifications
* EchoEvent now supports `extra` params for job delay and deduplication
* When Echo identifies this type of param it creates a
  DelayedEchoNotificationJob that will be executed after `delay` seconds

Change-Id: Ib0c6789dfe42e9703a67835909e5932c0054089f
2020-10-28 12:11:15 +01:00
Thiemo Kreuz e5fead8b42 Use more canonical (object)[] instead of new stdClass
Both styles create the exact same object. Casting an array to an
object creates an stdClass object as well. The main benefit of this
syntax is that there is much less repetition. Everything is one
token instead of individual lines, where each line might contain a
typo.

Change-Id: Id43fa2c4b6bd5d9dbc60008427d4a9e14ae3811c
2020-08-13 09:58:14 +00:00
Umherirrender 3c53d6acb9 phpcs: Break long lines
Use the codesniffer default of length = 120

Change-Id: Ifbfd56b20432e54805d3a9bce22cda888c1fc74d
2020-06-27 12:05:03 +02:00
Thiemo Kreuz 967a0b54e9 Use absolute class names in @covers tags
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
2019-10-23 12:23:09 +02:00
Roan Kattouw 95172c2c7e Remove per-type notify-type-availability (make it category-only)
Bug: T221264
Depends-On: I74f660e88d18d5a27cc1e74f39316bb27aec1cbb
Change-Id: I12cc0312dbfd9a6923b64117e001841a7bfaaf17
2019-04-26 17:36:10 -07:00
Thiemo Kreuz c36d2bd0e8 Prefer the …::class feature over hard-coded strings in all tests
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
2019-02-19 14:35:14 +00:00
Kunal Mehta 59a125fc38 Add @covers tags
Change-Id: Ib8cf432b58470c9218519639379c83254acef1c8
2018-01-23 16:44:45 -08:00
James D. Forrester 8c810dff48 build: Update mediawiki/mediawiki-codesniffer to 0.7.1
Also added "composer fix" command.

Change-Id: I25cb61b3b92798f1259d1575a336e2b056d5764f
2016-12-05 15:54:30 -08:00
Matthew Flaschen 5ecc6aa7c8 BREAKING CHANGE: Change $wgEchoDefaultNotificationTypes to be logical
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
2016-04-22 19:08:12 -07:00
Matthias Mullie cc11b3c81a Allow certain users to be excluded
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
2016-02-04 11:20:59 +01:00
Siebrand Mazeland 33126b69aa Update formatting
In preparation of Code Sniffer based updates.

Change-Id: Id5d43332b44a37665d57dc24ef8c432bc65b2f6a
2015-10-03 23:28:54 -04:00
Erik Bernhardson ae3b1f2944 Hygiene: Move notification type detection to method
* Moved most of the content from notify to getEventNotifyTypes
* Added phpunit test verifying per-event config overrides defaults
* Remove special-snowflake welcome handling with proper configuration

Change-Id: Ic1aae11d37f23f2b7b8abe3c1edaa414e29be021
2014-08-22 14:05:47 -07:00
bsitu 092127726b Hygiene: Echo/tests/phpunit/ directory structure should mimic Echo/
Change-Id: I4867d09bb815d621f9feaaf7b8a541e5d817e0d2
2014-08-21 22:58:27 +00:00