2014-07-22 21:33:22 +00:00
|
|
|
<?php
|
|
|
|
|
2021-02-25 02:46:03 +00:00
|
|
|
use MediaWiki\User\UserGroupManager;
|
|
|
|
use MediaWiki\User\UserIdentity;
|
2021-06-29 06:26:58 +00:00
|
|
|
use MediaWiki\User\UserOptionsLookup;
|
2021-02-25 02:46:03 +00:00
|
|
|
|
2014-07-22 21:33:22 +00:00
|
|
|
/**
|
|
|
|
* An object that manages attributes of echo notifications: category, elegibility,
|
|
|
|
* group, section etc.
|
|
|
|
*/
|
|
|
|
class EchoAttributeManager {
|
2021-02-25 02:46:03 +00:00
|
|
|
/**
|
|
|
|
* @var UserGroupManager
|
|
|
|
*/
|
|
|
|
private $userGroupManager;
|
2014-07-22 21:33:22 +00:00
|
|
|
|
2021-06-29 06:26:58 +00:00
|
|
|
/** @var UserOptionsLookup */
|
|
|
|
private $userOptionsLookup;
|
|
|
|
|
2014-07-22 21:33:22 +00:00
|
|
|
/**
|
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
|
|
|
|
*/
|
2020-09-19 18:55:32 +00:00
|
|
|
public const ALERT = 'alert';
|
|
|
|
public const MESSAGE = 'message';
|
|
|
|
public const ALL = 'all';
|
2014-08-05 21:50:54 +00:00
|
|
|
|
2020-12-16 21:31:09 +00:00
|
|
|
/** @var string */
|
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
|
|
|
|
*/
|
2020-09-19 18:55:32 +00:00
|
|
|
public const ATTR_LOCATORS = 'user-locators';
|
|
|
|
public const ATTR_FILTERS = 'user-filters';
|
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
|
|
|
|
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.
|
2021-02-25 02:46:03 +00:00
|
|
|
* @param UserGroupManager $userGroupManager
|
2021-06-29 06:26:58 +00:00
|
|
|
* @param UserOptionsLookup $userOptionsLookup
|
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,
|
2021-02-25 02:46:03 +00:00
|
|
|
array $notifyTypeAvailabilityByCategory,
|
2021-06-29 06:26:58 +00:00
|
|
|
UserGroupManager $userGroupManager,
|
|
|
|
UserOptionsLookup $userOptionsLookup
|
2018-08-25 10:51:14 +00:00
|
|
|
) {
|
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;
|
2021-02-25 02:46:03 +00:00
|
|
|
$this->userGroupManager = $userGroupManager;
|
2021-06-29 06:26:58 +00:00
|
|
|
$this->userOptionsLookup = $userOptionsLookup;
|
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
|
|
|
}
|
2019-03-01 22:34:38 +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
|
2021-06-29 06:26:58 +00:00
|
|
|
* @param UserIdentity $userIdentity
|
2016-12-28 11:29:44 +00:00
|
|
|
* @param string $notifyType Either "web" or "email".
|
2014-07-22 21:33:22 +00:00
|
|
|
* @return string[]
|
|
|
|
*/
|
2021-06-29 06:26:58 +00:00
|
|
|
public function getUserEnabledEvents( UserIdentity $userIdentity, $notifyType ) {
|
2019-04-12 22:34:28 +00:00
|
|
|
return array_values( array_filter(
|
|
|
|
array_keys( $this->notifications ),
|
2021-06-29 06:26:58 +00:00
|
|
|
function ( $eventType ) use ( $userIdentity, $notifyType ) {
|
2019-04-12 22:34:28 +00:00
|
|
|
$category = $this->getNotificationCategory( $eventType );
|
|
|
|
return $this->isNotifyTypeAvailableForCategory( $category, $notifyType ) &&
|
2021-06-29 06:26:58 +00:00
|
|
|
$this->getCategoryEligibility( $userIdentity, $category ) &&
|
|
|
|
$this->userOptionsLookup->getOption(
|
|
|
|
$userIdentity,
|
|
|
|
"echo-subscriptions-$notifyType-$category"
|
|
|
|
);
|
2014-07-22 21:33:22 +00:00
|
|
|
}
|
2019-04-12 22:34:28 +00:00
|
|
|
) );
|
2014-07-22 21:33:22 +00:00
|
|
|
}
|
|
|
|
|
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
|
2021-06-29 06:26:58 +00:00
|
|
|
* @param UserIdentity $userIdentity
|
2016-12-28 11:29:44 +00:00
|
|
|
* @param string $notifyType Either "web" or "email".
|
|
|
|
* @param string[] $sections
|
2014-08-05 21:50:54 +00:00
|
|
|
* @return string[]
|
|
|
|
*/
|
2021-06-29 06:26:58 +00:00
|
|
|
public function getUserEnabledEventsbySections(
|
|
|
|
UserIdentity $userIdentity,
|
|
|
|
$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(
|
2021-06-29 06:26:58 +00:00
|
|
|
$this->getUserEnabledEvents( $userIdentity, $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)
|
|
|
|
*
|
2021-06-29 06:26:58 +00:00
|
|
|
* @param UserIdentity $userIdentity
|
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 bool
|
2014-07-22 21:33:22 +00:00
|
|
|
*/
|
2021-06-29 06:26:58 +00:00
|
|
|
public function getCategoryEligibility( UserIdentity $userIdentity, $category ) {
|
|
|
|
$usersGroups = $this->userGroupManager->getUserGroups( $userIdentity );
|
2014-07-22 21:33:22 +00:00
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
2019-04-22 22:35:31 +00:00
|
|
|
/**
|
|
|
|
* Get notify type availability for all notify types for a given 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
|
|
|
|
* @return array [ 'web' => bool, 'email' => bool ]
|
|
|
|
*/
|
|
|
|
public function getNotifyTypeAvailabilityForCategory( $category ) {
|
|
|
|
return array_merge(
|
|
|
|
$this->defaultNotifyTypeAvailability,
|
|
|
|
$this->notifyTypeAvailabilityByCategory[$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
|
|
|
/**
|
|
|
|
* 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 ) {
|
2019-04-22 22:35:31 +00:00
|
|
|
return $this->getNotifyTypeAvailabilityForCategory( $category )[$notifyType];
|
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
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* 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 ) {
|
2019-05-07 16:52:01 +00:00
|
|
|
return $this->notifications[$notificationType]['section'] ?? 'alert';
|
2014-08-05 21:50:54 +00:00
|
|
|
}
|
|
|
|
|
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
|
|
|
}
|