2014-07-22 21:33:22 +00:00
|
|
|
<?php
|
|
|
|
|
|
|
|
/**
|
|
|
|
* An object that manages attributes of echo notifications: category, elegibility,
|
|
|
|
* group, section etc.
|
|
|
|
*/
|
|
|
|
class EchoAttributeManager {
|
|
|
|
|
|
|
|
/**
|
2018-08-13 07:25:22 +00:00
|
|
|
* @var array[]
|
2014-07-22 21:33:22 +00:00
|
|
|
*/
|
|
|
|
protected $notifications;
|
|
|
|
|
|
|
|
/**
|
2018-08-13 07:25:22 +00:00
|
|
|
* @var array[]
|
2014-07-22 21:33:22 +00:00
|
|
|
*/
|
|
|
|
protected $categories;
|
|
|
|
|
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-19 02:54:15 +00:00
|
|
|
/**
|
2018-08-13 07:25:22 +00:00
|
|
|
* @var bool[]
|
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-19 02:54:15 +00:00
|
|
|
*/
|
|
|
|
protected $defaultNotifyTypeAvailability;
|
|
|
|
|
|
|
|
/**
|
2018-08-13 07:25:22 +00:00
|
|
|
* @var array[]
|
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-19 02:54:15 +00:00
|
|
|
*/
|
|
|
|
protected $notifyTypeAvailabilityByCategory;
|
|
|
|
|
2014-08-05 21:50:54 +00:00
|
|
|
/**
|
|
|
|
* Notification section constant
|
|
|
|
*/
|
|
|
|
const ALERT = 'alert';
|
|
|
|
const MESSAGE = 'message';
|
|
|
|
const ALL = 'all';
|
|
|
|
|
2016-04-27 21:43:00 +00:00
|
|
|
protected static $DEFAULT_SECTION = self::ALERT;
|
|
|
|
|
2014-08-05 21:50:54 +00:00
|
|
|
/**
|
|
|
|
* Notifications are broken down to two sections, default is alert
|
2018-08-13 07:25:22 +00:00
|
|
|
* @var string[]
|
2014-08-05 21:50:54 +00:00
|
|
|
*/
|
2016-12-05 18:51:07 +00:00
|
|
|
public static $sections = [
|
2014-08-05 21:50:54 +00:00
|
|
|
self::ALERT,
|
|
|
|
self::MESSAGE
|
2016-12-05 18:51:07 +00:00
|
|
|
];
|
2014-08-05 21:50:54 +00:00
|
|
|
|
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-02 13:16:39 +00:00
|
|
|
/**
|
|
|
|
* Names for keys in $wgEchoNotifications notification config
|
|
|
|
*/
|
|
|
|
const ATTR_LOCATORS = 'user-locators';
|
|
|
|
const ATTR_FILTERS = 'user-filters';
|
|
|
|
|
2014-07-22 21:33:22 +00:00
|
|
|
/**
|
2015-07-31 19:19:53 +00:00
|
|
|
* An EchoAttributeManager instance created from global variables
|
2018-04-04 15:11:39 +00:00
|
|
|
* @var self
|
2014-07-22 21:33:22 +00:00
|
|
|
*/
|
2015-07-31 19:19:53 +00:00
|
|
|
protected static $globalVarInstance = null;
|
2014-07-22 21:33:22 +00:00
|
|
|
|
|
|
|
/**
|
2018-08-13 07:25:22 +00:00
|
|
|
* @param array[] $notifications Notification attributes
|
|
|
|
* @param array[] $categories Notification categories
|
|
|
|
* @param bool[] $defaultNotifyTypeAvailability Associative array with output
|
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-19 02:54:15 +00:00
|
|
|
* formats as keys and whether they are available as boolean values.
|
2018-08-13 07:25:22 +00:00
|
|
|
* @param array[] $notifyTypeAvailabilityByCategory Associative array with
|
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-19 02:54:15 +00:00
|
|
|
* categories as keys and value an associative array as with
|
|
|
|
* $defaultNotifyTypeAvailability.
|
2014-07-22 21:33:22 +00:00
|
|
|
*/
|
2018-08-25 10:51:14 +00:00
|
|
|
public function __construct(
|
|
|
|
array $notifications,
|
|
|
|
array $categories,
|
|
|
|
array $defaultNotifyTypeAvailability,
|
|
|
|
array $notifyTypeAvailabilityByCategory
|
|
|
|
) {
|
2014-07-22 21:33:22 +00:00
|
|
|
// Extensions can define their own notifications and categories
|
|
|
|
$this->notifications = $notifications;
|
|
|
|
$this->categories = $categories;
|
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-19 02:54:15 +00:00
|
|
|
|
|
|
|
$this->defaultNotifyTypeAvailability = $defaultNotifyTypeAvailability;
|
|
|
|
$this->notifyTypeAvailabilityByCategory = $notifyTypeAvailabilityByCategory;
|
2014-07-22 21:33:22 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Create an instance from global variables
|
|
|
|
* @return EchoAttributeManager
|
|
|
|
*/
|
|
|
|
public static function newFromGlobalVars() {
|
2018-08-25 10:51:14 +00:00
|
|
|
global $wgEchoNotifications, $wgEchoNotificationCategories,
|
|
|
|
$wgDefaultNotifyTypeAvailability, $wgNotifyTypeAvailabilityByCategory;
|
2014-07-22 21:33:22 +00:00
|
|
|
|
|
|
|
// Unit test may alter the global data for test purpose
|
2016-03-14 16:44:33 +00:00
|
|
|
if ( defined( 'MW_PHPUNIT_TEST' ) ) {
|
2018-08-25 10:51:14 +00:00
|
|
|
return new self(
|
|
|
|
$wgEchoNotifications,
|
|
|
|
$wgEchoNotificationCategories,
|
|
|
|
$wgDefaultNotifyTypeAvailability,
|
|
|
|
$wgNotifyTypeAvailabilityByCategory
|
|
|
|
);
|
2014-07-22 21:33:22 +00:00
|
|
|
}
|
2015-07-31 19:19:53 +00:00
|
|
|
|
|
|
|
if ( self::$globalVarInstance === null ) {
|
|
|
|
self::$globalVarInstance = new self(
|
2014-07-22 21:33:22 +00:00
|
|
|
$wgEchoNotifications,
|
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-19 02:54:15 +00:00
|
|
|
$wgEchoNotificationCategories,
|
|
|
|
$wgDefaultNotifyTypeAvailability,
|
2018-08-13 07:21:11 +00:00
|
|
|
$wgNotifyTypeAvailabilityByCategory
|
2014-07-22 21:33:22 +00:00
|
|
|
);
|
|
|
|
}
|
2015-10-01 13:48:52 +00:00
|
|
|
|
2015-07-31 19:19:53 +00:00
|
|
|
return self::$globalVarInstance;
|
2014-07-22 21:33:22 +00:00
|
|
|
}
|
|
|
|
|
2014-07-29 23:54:00 +00:00
|
|
|
/**
|
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-02 13:16:39 +00:00
|
|
|
* Get the user-locators|user-filters related to the provided event type
|
2014-07-29 23:54:00 +00:00
|
|
|
*
|
|
|
|
* @param string $type
|
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-02 13:16:39 +00:00
|
|
|
* @param string $locator Either self::ATTR_LOCATORS or self::ATTR_FILTERS
|
2014-07-29 23:54:00 +00:00
|
|
|
* @return array
|
|
|
|
*/
|
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-02 13:16:39 +00:00
|
|
|
public function getUserCallable( $type, $locator = self::ATTR_LOCATORS ) {
|
|
|
|
if ( isset( $this->notifications[$type][$locator] ) ) {
|
|
|
|
return (array)$this->notifications[$type][$locator];
|
2014-07-29 23:54:00 +00:00
|
|
|
} else {
|
2016-12-05 18:51:07 +00:00
|
|
|
return [];
|
2014-07-29 23:54:00 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-07-22 21:33:22 +00:00
|
|
|
/**
|
|
|
|
* Get the enabled events for a user, which excludes user-dismissed events
|
|
|
|
* from the general enabled events
|
2016-12-28 11:29:44 +00:00
|
|
|
* @param User $user
|
|
|
|
* @param string $notifyType Either "web" or "email".
|
2014-07-22 21:33:22 +00:00
|
|
|
* @return string[]
|
|
|
|
*/
|
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-19 02:54:15 +00:00
|
|
|
public function getUserEnabledEvents( User $user, $notifyType ) {
|
2014-07-22 21:33:22 +00:00
|
|
|
$eventTypesToLoad = $this->notifications;
|
|
|
|
foreach ( $eventTypesToLoad as $eventType => $eventData ) {
|
|
|
|
$category = $this->getNotificationCategory( $eventType );
|
2016-12-28 11:29:44 +00:00
|
|
|
// Make sure the user is eligible to receive this type of notification
|
2014-07-22 21:33:22 +00:00
|
|
|
if ( !$this->getCategoryEligibility( $user, $category ) ) {
|
|
|
|
unset( $eventTypesToLoad[$eventType] );
|
|
|
|
}
|
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-19 02:54:15 +00:00
|
|
|
if ( !$user->getOption( 'echo-subscriptions-' . $notifyType . '-' . $category ) ) {
|
2014-07-22 21:33:22 +00:00
|
|
|
unset( $eventTypesToLoad[$eventType] );
|
|
|
|
}
|
|
|
|
}
|
|
|
|
$eventTypes = array_keys( $eventTypesToLoad );
|
|
|
|
|
|
|
|
return $eventTypes;
|
|
|
|
}
|
|
|
|
|
2014-08-05 21:50:54 +00:00
|
|
|
/**
|
2016-12-28 11:29:44 +00:00
|
|
|
* Get the user enabled events for the specified sections
|
|
|
|
* @param User $user
|
|
|
|
* @param string $notifyType Either "web" or "email".
|
|
|
|
* @param string[] $sections
|
2014-08-05 21:50:54 +00:00
|
|
|
* @return string[]
|
|
|
|
*/
|
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-19 02:54:15 +00:00
|
|
|
public function getUserEnabledEventsbySections( User $user, $notifyType, array $sections ) {
|
2016-12-05 18:51:07 +00:00
|
|
|
$events = [];
|
2014-08-05 21:50:54 +00:00
|
|
|
foreach ( $sections as $section ) {
|
|
|
|
$events = array_merge(
|
|
|
|
$events,
|
2016-04-27 21:43:00 +00:00
|
|
|
$this->getEventsForSection( $section )
|
2014-08-05 21:50:54 +00:00
|
|
|
);
|
|
|
|
}
|
2015-10-01 13:48:52 +00:00
|
|
|
|
2014-08-05 21:50:54 +00:00
|
|
|
return array_intersect(
|
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-19 02:54:15 +00:00
|
|
|
$this->getUserEnabledEvents( $user, $notifyType ),
|
2014-08-05 21:50:54 +00:00
|
|
|
$events
|
|
|
|
);
|
|
|
|
}
|
|
|
|
|
2014-07-22 21:33:22 +00:00
|
|
|
/**
|
2016-04-27 21:43:00 +00:00
|
|
|
* Gets events (notification types) for a given section
|
|
|
|
*
|
|
|
|
* @param string $section Internal section name, one of the values from self::$sections
|
|
|
|
*
|
2018-08-13 07:25:22 +00:00
|
|
|
* @return string[] Array of notification types in this section
|
2014-07-22 21:33:22 +00:00
|
|
|
*/
|
2016-04-27 21:43:00 +00:00
|
|
|
public function getEventsForSection( $section ) {
|
2016-12-05 18:51:07 +00:00
|
|
|
$events = [];
|
2015-10-01 13:48:52 +00:00
|
|
|
|
2016-04-27 21:43:00 +00:00
|
|
|
$isDefault = ( $section === self::$DEFAULT_SECTION );
|
2014-08-05 21:50:54 +00:00
|
|
|
|
|
|
|
foreach ( $this->notifications as $event => $attribs ) {
|
|
|
|
if (
|
2016-04-27 21:43:00 +00:00
|
|
|
(
|
|
|
|
isset( $attribs['section'] ) &&
|
|
|
|
$attribs['section'] === $section
|
|
|
|
) ||
|
|
|
|
(
|
|
|
|
$isDefault &&
|
|
|
|
(
|
|
|
|
!isset( $attribs['section'] ) ||
|
|
|
|
|
|
|
|
// Invalid section
|
|
|
|
!in_array( $attribs['section'], self::$sections )
|
|
|
|
)
|
|
|
|
)
|
|
|
|
|
2014-08-05 21:50:54 +00:00
|
|
|
) {
|
|
|
|
$events[] = $event;
|
|
|
|
}
|
|
|
|
}
|
2015-10-01 13:48:52 +00:00
|
|
|
|
2014-08-05 21:50:54 +00:00
|
|
|
return $events;
|
2014-07-22 21:33:22 +00:00
|
|
|
}
|
|
|
|
|
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-19 02:54:15 +00:00
|
|
|
/**
|
|
|
|
* Gets array of internal category names
|
|
|
|
*
|
2018-08-13 07:25:22 +00:00
|
|
|
* @return string[] All internal names
|
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-19 02:54:15 +00:00
|
|
|
*/
|
|
|
|
public function getInternalCategoryNames() {
|
|
|
|
return array_keys( $this->categories );
|
|
|
|
}
|
|
|
|
|
2014-07-22 21:33:22 +00:00
|
|
|
/**
|
2016-12-28 11:29:44 +00:00
|
|
|
* See if a user is eligible to receive a certain type of notification
|
2014-07-22 21:33:22 +00:00
|
|
|
* (based on user groups, not user preferences)
|
|
|
|
*
|
2017-08-09 15:20:55 +00:00
|
|
|
* @param User $user
|
|
|
|
* @param string $category A notification category defined in $wgEchoNotificationCategories
|
2017-07-26 19:34:44 +00:00
|
|
|
* @return bool
|
2014-07-22 21:33:22 +00:00
|
|
|
*/
|
|
|
|
public function getCategoryEligibility( $user, $category ) {
|
|
|
|
$usersGroups = $user->getGroups();
|
|
|
|
if ( isset( $this->categories[$category]['usergroups'] ) ) {
|
|
|
|
$allowedGroups = $this->categories[$category]['usergroups'];
|
|
|
|
if ( !array_intersect( $usersGroups, $allowedGroups ) ) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
2015-10-01 13:48:52 +00:00
|
|
|
|
2014-07-22 21:33:22 +00:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Get the priority for a specific notification type
|
|
|
|
*
|
2017-08-09 15:20:55 +00:00
|
|
|
* @param string $notificationType A notification type defined in $wgEchoNotifications
|
2017-07-26 19:34:44 +00:00
|
|
|
* @return int From 1 to 10 (10 is default)
|
2014-07-22 21:33:22 +00:00
|
|
|
*/
|
|
|
|
public function getNotificationPriority( $notificationType ) {
|
|
|
|
$category = $this->getNotificationCategory( $notificationType );
|
2015-10-01 13:48:52 +00:00
|
|
|
|
2014-07-22 21:33:22 +00:00
|
|
|
return $this->getCategoryPriority( $category );
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Get the priority for a notification category
|
|
|
|
*
|
2017-08-09 15:20:55 +00:00
|
|
|
* @param string $category A notification category defined in $wgEchoNotificationCategories
|
2017-07-26 19:34:44 +00:00
|
|
|
* @return int From 1 to 10 (10 is default)
|
2014-07-22 21:33:22 +00:00
|
|
|
*/
|
|
|
|
public function getCategoryPriority( $category ) {
|
|
|
|
if ( isset( $this->categories[$category]['priority'] ) ) {
|
|
|
|
$priority = $this->categories[$category]['priority'];
|
|
|
|
if ( $priority >= 1 && $priority <= 10 ) {
|
|
|
|
return $priority;
|
|
|
|
}
|
|
|
|
}
|
2015-10-01 13:48:52 +00:00
|
|
|
|
2014-07-22 21:33:22 +00:00
|
|
|
return 10;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Get the notification category for a notification type
|
|
|
|
*
|
2017-08-09 15:20:55 +00:00
|
|
|
* @param string $notificationType A notification type defined in $wgEchoNotifications
|
2014-07-22 21:33:22 +00:00
|
|
|
* @return string The name of the notification category or 'other' if no
|
|
|
|
* category is explicitly assigned.
|
|
|
|
*/
|
|
|
|
public function getNotificationCategory( $notificationType ) {
|
|
|
|
if ( isset( $this->notifications[$notificationType]['category'] ) ) {
|
|
|
|
$category = $this->notifications[$notificationType]['category'];
|
|
|
|
if ( isset( $this->categories[$category] ) ) {
|
|
|
|
return $category;
|
|
|
|
}
|
|
|
|
}
|
2015-10-01 13:48:52 +00:00
|
|
|
|
2014-07-22 21:33:22 +00:00
|
|
|
return 'other';
|
|
|
|
}
|
2014-08-05 21:50:54 +00:00
|
|
|
|
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-19 02:54:15 +00:00
|
|
|
/**
|
|
|
|
* Gets an associative array mapping categories to the notification types in
|
|
|
|
* the category
|
|
|
|
*
|
2018-08-13 07:25:22 +00:00
|
|
|
* @return array[] Associative array with category as key
|
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-19 02:54:15 +00:00
|
|
|
*/
|
|
|
|
public function getEventsByCategory() {
|
2016-12-05 18:51:07 +00:00
|
|
|
$eventsByCategory = [];
|
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-19 02:54:15 +00:00
|
|
|
|
|
|
|
foreach ( $this->categories as $category => $categoryDetails ) {
|
2016-12-05 18:51:07 +00:00
|
|
|
$eventsByCategory[$category] = [];
|
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-19 02:54:15 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
foreach ( $this->notifications as $notificationType => $notificationDetails ) {
|
|
|
|
$category = $notificationDetails['category'];
|
|
|
|
if ( isset( $eventsByCategory[$category] ) ) {
|
|
|
|
// Only real categories. Currently, this excludes the 'foreign'
|
2018-08-25 10:25:16 +00:00
|
|
|
// pseudo-category.
|
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-19 02:54:15 +00:00
|
|
|
$eventsByCategory[$category][] = $notificationType;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return $eventsByCategory;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Checks whether the specified notify type is available for the specified
|
|
|
|
* category.
|
|
|
|
*
|
|
|
|
* This means whether users *can* turn notifications for this category and format
|
|
|
|
* on, regardless of the default or a particular user's preferences.
|
|
|
|
*
|
|
|
|
* @param string $category Category name
|
|
|
|
* @param string $notifyType notify type, e.g. email/web.
|
2017-08-09 15:20:55 +00:00
|
|
|
* @return bool
|
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-19 02:54:15 +00:00
|
|
|
*/
|
|
|
|
public function isNotifyTypeAvailableForCategory( $category, $notifyType ) {
|
|
|
|
if ( isset( $this->notifyTypeAvailabilityByCategory[$category][$notifyType] ) ) {
|
|
|
|
return $this->notifyTypeAvailabilityByCategory[$category][$notifyType];
|
|
|
|
} else {
|
|
|
|
return $this->defaultNotifyTypeAvailability[$notifyType];
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Checks whether category is displayed in preferences
|
|
|
|
*
|
|
|
|
* @param string $category Category name
|
2017-08-09 15:20:55 +00:00
|
|
|
* @return bool
|
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-19 02:54:15 +00:00
|
|
|
*/
|
|
|
|
public function isCategoryDisplayedInPreferences( $category ) {
|
|
|
|
return !(
|
|
|
|
isset( $this->categories[$category]['no-dismiss'] ) &&
|
|
|
|
in_array( 'all', $this->categories[$category]['no-dismiss'] )
|
|
|
|
);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Checks whether the specified notify type is dismissable for the specified
|
|
|
|
* category.
|
|
|
|
*
|
|
|
|
* This means whether the user is allowed to opt out of receiving notifications
|
|
|
|
* for this category and format.
|
|
|
|
*
|
|
|
|
* @param string $category Name of category
|
|
|
|
* @param string $notifyType notify type, e.g. email/web.
|
2017-08-09 15:20:55 +00:00
|
|
|
* @return bool
|
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-19 02:54:15 +00:00
|
|
|
*/
|
|
|
|
public function isNotifyTypeDismissableForCategory( $category, $notifyType ) {
|
|
|
|
return !(
|
|
|
|
isset( $this->categories[$category]['no-dismiss'] ) &&
|
|
|
|
(
|
|
|
|
in_array( 'all', $this->categories[$category]['no-dismiss'] ) ||
|
|
|
|
in_array( $notifyType, $this->categories[$category]['no-dismiss'] )
|
|
|
|
)
|
|
|
|
);
|
|
|
|
}
|
|
|
|
|
2014-08-05 21:50:54 +00:00
|
|
|
/**
|
|
|
|
* Get notification section for a notification type
|
|
|
|
* @todo add a unit test case
|
2016-03-07 19:48:39 +00:00
|
|
|
* @param string $notificationType
|
2014-08-05 21:50:54 +00:00
|
|
|
* @return string
|
|
|
|
*/
|
|
|
|
public function getNotificationSection( $notificationType ) {
|
|
|
|
if ( isset( $this->notifications[$notificationType]['section'] ) ) {
|
|
|
|
return $this->notifications[$notificationType]['section'];
|
|
|
|
}
|
2015-10-01 13:48:52 +00:00
|
|
|
|
2014-08-05 21:50:54 +00:00
|
|
|
return 'alert';
|
|
|
|
}
|
|
|
|
|
2018-10-26 23:46:16 +00:00
|
|
|
/**
|
|
|
|
* Get notification types that allow their own agent to be notified.
|
|
|
|
*
|
|
|
|
* @return string[] Notification types
|
|
|
|
*/
|
|
|
|
public function getNotifyAgentEvents() {
|
|
|
|
$events = [];
|
|
|
|
foreach ( $this->notifications as $event => $attribs ) {
|
|
|
|
if ( $attribs['canNotifyAgent'] ?? false ) {
|
|
|
|
$events[] = $event;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return $events;
|
|
|
|
}
|
|
|
|
|
2014-07-22 21:33:22 +00:00
|
|
|
}
|