2014-07-22 21:33:22 +00:00
|
|
|
<?php
|
|
|
|
|
|
|
|
class EchoAttributeManagerTest extends MediaWikiTestCase {
|
|
|
|
|
|
|
|
public function testNewFromGlobalVars() {
|
|
|
|
$this->assertInstanceOf( 'EchoAttributeManager', EchoAttributeManager::newFromGlobalVars() );
|
|
|
|
}
|
|
|
|
|
2014-07-29 23:54:00 +00:00
|
|
|
public static function getUserLocatorsProvider() {
|
|
|
|
return array(
|
|
|
|
array(
|
|
|
|
'No errors when requesting unknown type',
|
|
|
|
// expected result
|
|
|
|
array(),
|
|
|
|
// event type
|
|
|
|
'foo',
|
|
|
|
// notification configuration
|
|
|
|
array(),
|
|
|
|
),
|
|
|
|
|
|
|
|
array(
|
|
|
|
'Returns selected notification configuration',
|
|
|
|
// expected result
|
|
|
|
array( 'woot!' ),
|
|
|
|
// event type
|
|
|
|
'magic',
|
|
|
|
// notification configuration
|
|
|
|
array(
|
|
|
|
'foo' => 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
|
|
|
EchoAttributeManager::ATTR_LOCATORS => array( 'frown' ),
|
2014-07-29 23:54:00 +00:00
|
|
|
),
|
|
|
|
'magic' => 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
|
|
|
EchoAttributeManager::ATTR_LOCATORS => array( 'woot!' ),
|
2014-07-29 23:54:00 +00:00
|
|
|
),
|
|
|
|
),
|
|
|
|
),
|
|
|
|
|
|
|
|
array(
|
|
|
|
'Accepts user-locators as string and returns array',
|
|
|
|
// expected result
|
|
|
|
array( 'sagen' ),
|
|
|
|
// event type
|
|
|
|
'challah',
|
|
|
|
// notification configuration
|
|
|
|
array(
|
|
|
|
'challah' => 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
|
|
|
EchoAttributeManager::ATTR_LOCATORS => 'sagen',
|
2014-07-29 23:54:00 +00:00
|
|
|
),
|
|
|
|
),
|
|
|
|
),
|
|
|
|
);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @dataProvider getUserLocatorsProvider
|
|
|
|
*/
|
2015-10-01 13:48:52 +00:00
|
|
|
public function testGetUserLocators( $message, $expect, $type, $notifications ) {
|
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
|
|
|
$manager = new EchoAttributeManager( $notifications, array(), array(), array(), array() );
|
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
|
|
|
$result = $manager->getUserCallable( $type, EchoAttributeManager::ATTR_LOCATORS );
|
2014-07-29 23:54:00 +00:00
|
|
|
$this->assertEquals( $expect, $result, $message );
|
|
|
|
}
|
|
|
|
|
2014-07-22 21:33:22 +00:00
|
|
|
public function testGetCategoryEligibility() {
|
|
|
|
$notif = array(
|
2015-10-01 13:48:52 +00:00
|
|
|
'event_one' => array(
|
2014-07-22 21:33:22 +00:00
|
|
|
'category' => 'category_one'
|
|
|
|
),
|
|
|
|
);
|
|
|
|
$category = array(
|
2015-10-01 13:48:52 +00:00
|
|
|
'category_one' => array(
|
2014-07-22 21:33:22 +00:00
|
|
|
'priority' => 10
|
|
|
|
)
|
|
|
|
);
|
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
|
|
|
$manager = new EchoAttributeManager( $notif, $category, array(), array(), array() );
|
2014-07-22 21:33:22 +00:00
|
|
|
$this->assertTrue( $manager->getCategoryEligibility( $this->mockUser(), 'category_one' ) );
|
|
|
|
$category = array(
|
2015-10-01 13:48:52 +00:00
|
|
|
'category_one' => array(
|
2014-07-22 21:33:22 +00:00
|
|
|
'priority' => 10,
|
|
|
|
'usergroups' => array(
|
|
|
|
'sysop'
|
|
|
|
)
|
|
|
|
)
|
|
|
|
);
|
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
|
|
|
$manager = new EchoAttributeManager( $notif, $category, array(), array(), array() );
|
2014-07-22 21:33:22 +00:00
|
|
|
$this->assertFalse( $manager->getCategoryEligibility( $this->mockUser(), 'category_one' ) );
|
|
|
|
}
|
|
|
|
|
|
|
|
public function testGetNotificationCategory() {
|
|
|
|
$notif = array(
|
2015-10-01 13:48:52 +00:00
|
|
|
'event_one' => array(
|
2014-07-22 21:33:22 +00:00
|
|
|
'category' => 'category_one'
|
|
|
|
),
|
|
|
|
);
|
|
|
|
$category = array(
|
2015-10-01 13:48:52 +00:00
|
|
|
'category_one' => array(
|
2014-07-22 21:33:22 +00:00
|
|
|
'priority' => 10
|
|
|
|
)
|
|
|
|
);
|
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
|
|
|
$manager = new EchoAttributeManager( $notif, $category, array(), array(), array() );
|
2014-07-22 21:33:22 +00:00
|
|
|
$this->assertEquals( $manager->getNotificationCategory( 'event_one' ), 'category_one' );
|
|
|
|
|
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
|
|
|
$manager = new EchoAttributeManager( $notif, array(), array(), array(), array() );
|
2014-07-22 21:33:22 +00:00
|
|
|
$this->assertEquals( $manager->getNotificationCategory( 'event_one' ), 'other' );
|
|
|
|
|
|
|
|
$notif = array(
|
2015-10-01 13:48:52 +00:00
|
|
|
'event_one' => array(
|
2014-07-22 21:33:22 +00:00
|
|
|
'category' => 'category_two'
|
|
|
|
),
|
|
|
|
);
|
|
|
|
$category = array(
|
2015-10-01 13:48:52 +00:00
|
|
|
'category_one' => array(
|
2014-07-22 21:33:22 +00:00
|
|
|
'priority' => 10
|
|
|
|
)
|
|
|
|
);
|
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
|
|
|
$manager = new EchoAttributeManager( $notif, $category, array(), array(), array() );
|
2014-07-22 21:33:22 +00:00
|
|
|
$this->assertEquals( $manager->getNotificationCategory( 'event_one' ), 'other' );
|
|
|
|
}
|
|
|
|
|
|
|
|
public function testGetCategoryPriority() {
|
|
|
|
$notif = array(
|
2015-10-01 13:48:52 +00:00
|
|
|
'event_one' => array(
|
2014-07-22 21:33:22 +00:00
|
|
|
'category' => 'category_two'
|
|
|
|
),
|
|
|
|
);
|
|
|
|
$category = array(
|
2015-10-01 13:48:52 +00:00
|
|
|
'category_one' => array(
|
2014-07-22 21:33:22 +00:00
|
|
|
'priority' => 6
|
|
|
|
),
|
2015-10-01 13:48:52 +00:00
|
|
|
'category_two' => array(
|
2014-07-22 21:33:22 +00:00
|
|
|
'priority' => 100
|
|
|
|
),
|
2015-10-01 13:48:52 +00:00
|
|
|
'category_three' => array(
|
2014-07-22 21:33:22 +00:00
|
|
|
'priority' => -10
|
|
|
|
),
|
2015-10-01 13:48:52 +00:00
|
|
|
'category_four' => array()
|
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
|
|
|
$manager = new EchoAttributeManager( $notif, $category, array(), array(), array() );
|
2014-07-22 21:33:22 +00:00
|
|
|
$this->assertEquals( 6, $manager->getCategoryPriority( 'category_one' ) );
|
|
|
|
$this->assertEquals( 10, $manager->getCategoryPriority( 'category_two' ) );
|
|
|
|
$this->assertEquals( 10, $manager->getCategoryPriority( 'category_three' ) );
|
|
|
|
$this->assertEquals( 10, $manager->getCategoryPriority( 'category_four' ) );
|
|
|
|
}
|
|
|
|
|
|
|
|
public function testGetNotificationPriority() {
|
|
|
|
$notif = array(
|
2015-10-01 13:48:52 +00:00
|
|
|
'event_one' => array(
|
2014-07-22 21:33:22 +00:00
|
|
|
'category' => 'category_one'
|
|
|
|
),
|
2015-10-01 13:48:52 +00:00
|
|
|
'event_two' => array(
|
2014-07-22 21:33:22 +00:00
|
|
|
'category' => 'category_two'
|
|
|
|
),
|
2015-10-01 13:48:52 +00:00
|
|
|
'event_three' => array(
|
2014-07-22 21:33:22 +00:00
|
|
|
'category' => 'category_three'
|
|
|
|
),
|
2015-10-01 13:48:52 +00:00
|
|
|
'event_four' => array(
|
2014-07-22 21:33:22 +00:00
|
|
|
'category' => 'category_four'
|
|
|
|
)
|
|
|
|
);
|
|
|
|
$category = array(
|
2015-10-01 13:48:52 +00:00
|
|
|
'category_one' => array(
|
2014-07-22 21:33:22 +00:00
|
|
|
'priority' => 6
|
|
|
|
),
|
2015-10-01 13:48:52 +00:00
|
|
|
'category_two' => array(
|
2014-07-22 21:33:22 +00:00
|
|
|
'priority' => 100
|
|
|
|
),
|
2015-10-01 13:48:52 +00:00
|
|
|
'category_three' => array(
|
2014-07-22 21:33:22 +00:00
|
|
|
'priority' => -10
|
|
|
|
),
|
2015-10-01 13:48:52 +00:00
|
|
|
'category_four' => array()
|
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
|
|
|
$manager = new EchoAttributeManager( $notif, $category, array(), array(), array() );
|
2014-07-22 21:33:22 +00:00
|
|
|
$this->assertEquals( 6, $manager->getNotificationPriority( 'event_one' ) );
|
|
|
|
$this->assertEquals( 10, $manager->getNotificationPriority( 'event_two' ) );
|
|
|
|
$this->assertEquals( 10, $manager->getNotificationPriority( 'event_three' ) );
|
|
|
|
$this->assertEquals( 10, $manager->getNotificationPriority( 'event_four' ) );
|
|
|
|
}
|
|
|
|
|
2016-04-27 21:43:00 +00:00
|
|
|
public static function getEventsForSectionProvider() {
|
|
|
|
$notifications = array(
|
2015-10-01 13:48:52 +00:00
|
|
|
'event_one' => array(
|
2014-08-05 21:50:54 +00:00
|
|
|
'category' => 'category_one',
|
2016-04-27 21:43:00 +00:00
|
|
|
'section' => 'message',
|
2014-08-05 21:50:54 +00:00
|
|
|
),
|
2015-10-01 13:48:52 +00:00
|
|
|
'event_two' => array(
|
2016-04-27 21:43:00 +00:00
|
|
|
'category' => 'category_two',
|
|
|
|
'section' => 'invalid',
|
2014-08-05 21:50:54 +00:00
|
|
|
),
|
2015-10-01 13:48:52 +00:00
|
|
|
'event_three' => array(
|
2014-08-05 21:50:54 +00:00
|
|
|
'category' => 'category_three',
|
2016-04-27 21:43:00 +00:00
|
|
|
'section' => 'message',
|
2014-08-05 21:50:54 +00:00
|
|
|
),
|
2015-10-01 13:48:52 +00:00
|
|
|
'event_four' => array(
|
2016-04-27 21:43:00 +00:00
|
|
|
'category' => 'category_four',
|
|
|
|
// Omitted
|
|
|
|
),
|
|
|
|
'event_five' => array(
|
|
|
|
'category' => 'category_two',
|
|
|
|
'section' => 'alert',
|
|
|
|
),
|
2014-08-05 21:50:54 +00:00
|
|
|
);
|
|
|
|
|
2016-04-27 21:43:00 +00:00
|
|
|
return array(
|
|
|
|
array(
|
|
|
|
array( 'event_one', 'event_three' ),
|
|
|
|
$notifications,
|
|
|
|
'message',
|
|
|
|
'Messages',
|
2014-08-05 21:50:54 +00:00
|
|
|
),
|
2016-04-27 21:43:00 +00:00
|
|
|
|
|
|
|
array(
|
|
|
|
array( 'event_two', 'event_four', 'event_five' ),
|
|
|
|
$notifications,
|
|
|
|
'alert',
|
|
|
|
'Alerts',
|
2014-08-05 21:50:54 +00:00
|
|
|
),
|
|
|
|
);
|
2016-04-27 21:43:00 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @dataProvider getEventsForSectionProvider
|
|
|
|
*/
|
|
|
|
public function testGetEventsForSection( $expected, $notificationTypes, $section, $message ) {
|
|
|
|
$am = new EchoAttributeManager( $notificationTypes, array(), array(), array(), array() );
|
|
|
|
$actual = $am->getEventsForSection( $section );
|
|
|
|
$this->assertEquals( $expected, $actual, $message );
|
2014-08-05 21:50:54 +00:00
|
|
|
}
|
|
|
|
|
2014-07-22 21:33:22 +00:00
|
|
|
public function testGetUserEnabledEvents() {
|
|
|
|
$notif = array(
|
2015-10-01 13:48:52 +00:00
|
|
|
'event_one' => array(
|
2014-07-22 21:33:22 +00:00
|
|
|
'category' => 'category_one'
|
|
|
|
),
|
2015-10-01 13:48:52 +00:00
|
|
|
'event_two' => array(
|
2014-07-22 21:33:22 +00:00
|
|
|
'category' => 'category_two'
|
|
|
|
),
|
2015-10-01 13:48:52 +00:00
|
|
|
'event_three' => array(
|
2014-07-22 21:33:22 +00:00
|
|
|
'category' => 'category_three'
|
|
|
|
),
|
|
|
|
);
|
|
|
|
$category = array(
|
2015-10-01 13:48:52 +00:00
|
|
|
'category_one' => array(
|
2014-07-22 21:33:22 +00:00
|
|
|
'priority' => 10,
|
|
|
|
'usergroups' => array(
|
|
|
|
'sysop'
|
|
|
|
)
|
|
|
|
),
|
2015-10-01 13:48:52 +00:00
|
|
|
'category_two' => array(
|
2014-07-22 21:33:22 +00:00
|
|
|
'priority' => 10,
|
|
|
|
'usergroups' => array(
|
|
|
|
'echo_group'
|
|
|
|
)
|
|
|
|
),
|
2015-10-01 13:48:52 +00:00
|
|
|
'category_three' => array(
|
2014-07-22 21:33:22 +00:00
|
|
|
'priority' => 10,
|
|
|
|
),
|
|
|
|
);
|
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
|
|
|
$manager = new EchoAttributeManager( $notif, $category, array(), array(), array() );
|
2014-07-22 21:33:22 +00:00
|
|
|
$this->assertEquals( $manager->getUserEnabledEvents( $this->mockUser(), 'web' ), array( 'event_two', 'event_three' ) );
|
|
|
|
}
|
|
|
|
|
2014-08-05 21:50:54 +00:00
|
|
|
public function testGetUserEnabledEventsbySections() {
|
|
|
|
$notif = array(
|
2015-10-01 13:48:52 +00:00
|
|
|
'event_one' => array(
|
2014-08-05 21:50:54 +00:00
|
|
|
'category' => 'category_one'
|
|
|
|
),
|
2015-10-01 13:48:52 +00:00
|
|
|
'event_two' => array(
|
2014-08-05 21:50:54 +00:00
|
|
|
'category' => 'category_two',
|
|
|
|
'section' => 'message'
|
|
|
|
),
|
2015-10-01 13:48:52 +00:00
|
|
|
'event_three' => array(
|
2014-08-05 21:50:54 +00:00
|
|
|
'category' => 'category_three',
|
|
|
|
'section' => 'alert'
|
|
|
|
),
|
2015-10-01 13:48:52 +00:00
|
|
|
'event_four' => array(
|
2014-08-05 21:50:54 +00:00
|
|
|
'category' => 'category_three',
|
|
|
|
),
|
|
|
|
);
|
|
|
|
$category = array(
|
2015-10-01 13:48:52 +00:00
|
|
|
'category_one' => array(
|
2014-08-05 21:50:54 +00:00
|
|
|
'priority' => 10,
|
|
|
|
),
|
2015-10-01 13:48:52 +00:00
|
|
|
'category_two' => array(
|
2014-08-05 21:50:54 +00:00
|
|
|
'priority' => 10,
|
|
|
|
),
|
2015-10-01 13:48:52 +00:00
|
|
|
'category_three' => array(
|
2014-08-05 21:50:54 +00:00
|
|
|
'priority' => 10
|
|
|
|
),
|
|
|
|
);
|
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
|
|
|
$manager = new EchoAttributeManager( $notif, $category, array(), array(), array() );
|
2014-08-05 21:50:54 +00:00
|
|
|
$expected = array( 'event_one', 'event_three', 'event_four' );
|
|
|
|
$actual = $manager->getUserEnabledEventsBySections( $this->mockUser(), 'web', array( 'alert' ) );
|
|
|
|
sort( $expected );
|
|
|
|
sort( $actual );
|
|
|
|
$this->assertEquals( $actual, $expected );
|
|
|
|
|
|
|
|
$expected = array( 'event_two' );
|
|
|
|
$actual = $manager->getUserEnabledEventsBySections( $this->mockUser(), 'web', array( 'message' ) );
|
|
|
|
sort( $expected );
|
|
|
|
sort( $actual );
|
|
|
|
$this->assertEquals( $actual, $expected );
|
|
|
|
|
|
|
|
$expected = array( 'event_one', 'event_two', 'event_three', 'event_four' );
|
|
|
|
$actual = $manager->getUserEnabledEventsBySections( $this->mockUser(), 'web', array( 'message', 'alert' ) );
|
|
|
|
sort( $expected );
|
|
|
|
sort( $actual );
|
|
|
|
$this->assertEquals( $actual, $expected );
|
|
|
|
}
|
|
|
|
|
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 static function getEventsByCategoryProvider() {
|
|
|
|
return array(
|
|
|
|
array(
|
|
|
|
'Mix of populated and empty categories handled appropriately',
|
|
|
|
array(
|
|
|
|
'category_one' => array(
|
|
|
|
'event_two',
|
|
|
|
'event_five',
|
|
|
|
),
|
|
|
|
'category_two' => array(
|
|
|
|
'event_one',
|
|
|
|
'event_three',
|
|
|
|
'event_four',
|
|
|
|
),
|
|
|
|
'category_three' => array(),
|
|
|
|
),
|
|
|
|
array(
|
|
|
|
'category_one' => array(),
|
|
|
|
'category_two' => array(),
|
|
|
|
'category_three' => array(),
|
|
|
|
),
|
|
|
|
array(
|
|
|
|
'event_one' => array(
|
|
|
|
'category' => 'category_two',
|
|
|
|
),
|
|
|
|
'event_two' => array(
|
|
|
|
'category' => 'category_one',
|
|
|
|
),
|
|
|
|
'event_three' => array(
|
|
|
|
'category' => 'category_two',
|
|
|
|
),
|
|
|
|
'event_four' => array(
|
|
|
|
'category' => 'category_two',
|
|
|
|
),
|
|
|
|
'event_five' => array(
|
|
|
|
'category' => 'category_one',
|
|
|
|
),
|
|
|
|
)
|
|
|
|
)
|
|
|
|
);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @dataProvider getEventsByCategoryProvider
|
|
|
|
*/
|
|
|
|
public function testGetEventsByCategory( $message, $expectedMapping, $categories, $notifications ) {
|
|
|
|
$am = new EchoAttributeManager( $notifications, $categories, array(), array(), array() );
|
|
|
|
$actualMapping = $am->getEventsByCategory();
|
|
|
|
$this->assertEquals( $expectedMapping, $actualMapping, $message );
|
|
|
|
}
|
|
|
|
|
|
|
|
public static function isNotifyTypeAvailableForCategoryProvider() {
|
|
|
|
return array(
|
|
|
|
array(
|
|
|
|
'Fallback to default entirely',
|
|
|
|
true,
|
|
|
|
'category_one',
|
|
|
|
'web',
|
|
|
|
array( 'web' => true, 'email' => true ),
|
|
|
|
array()
|
|
|
|
),
|
|
|
|
array(
|
|
|
|
'Fallback to default for single type',
|
|
|
|
false,
|
|
|
|
'category_two',
|
|
|
|
'email',
|
|
|
|
array( 'web' => true, 'email' => false ),
|
|
|
|
array(
|
|
|
|
'category_two' => array(
|
|
|
|
'web' => true,
|
|
|
|
),
|
|
|
|
)
|
|
|
|
),
|
|
|
|
array(
|
|
|
|
'Use override',
|
|
|
|
false,
|
|
|
|
'category_three',
|
|
|
|
'web',
|
|
|
|
array( 'web' => true, 'email' => true ),
|
|
|
|
array(
|
|
|
|
'category_three' => array(
|
|
|
|
'web' => false,
|
|
|
|
),
|
|
|
|
),
|
|
|
|
),
|
|
|
|
);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
@dataProvider isNotifyTypeAvailableForCategoryProvider
|
|
|
|
*/
|
|
|
|
public function testIsNotifyTypeAvailableForCategory( $message, $expected, $categoryName, $notifyType, $defaultNotifyTypeAvailability, $notifyTypeAvailabilityByCategory ) {
|
|
|
|
$am = new EchoAttributeManager( array(), array(), $defaultNotifyTypeAvailability, $notifyTypeAvailabilityByCategory, array() );
|
|
|
|
$actual = $am->isNotifyTypeAvailableForCategory( $categoryName, $notifyType );
|
|
|
|
$this->assertEquals( $expected, $actual, $message );
|
|
|
|
}
|
|
|
|
|
|
|
|
public static function isNotifyTypeDismissableForCategoryProvider() {
|
|
|
|
return array(
|
|
|
|
array(
|
|
|
|
'Not dismissable because of all',
|
|
|
|
false,
|
|
|
|
array(
|
|
|
|
'category_one' => array(
|
|
|
|
'no-dismiss' => array( 'all' ),
|
|
|
|
)
|
|
|
|
),
|
|
|
|
'category_one',
|
|
|
|
'web',
|
|
|
|
),
|
|
|
|
array(
|
|
|
|
'Not dismissable because of specific notify type',
|
|
|
|
false,
|
|
|
|
array(
|
|
|
|
'category_two' => array(
|
|
|
|
'no-dismiss' => array( 'email' ),
|
|
|
|
)
|
|
|
|
),
|
|
|
|
'category_two',
|
|
|
|
'email',
|
|
|
|
),
|
|
|
|
array(
|
|
|
|
'Dismissable because of different affected notify type',
|
|
|
|
true,
|
|
|
|
array(
|
|
|
|
'category_three' => array(
|
|
|
|
'no-dismiss' => array( 'web' ),
|
|
|
|
)
|
|
|
|
),
|
|
|
|
'category_three',
|
|
|
|
'email',
|
|
|
|
),
|
|
|
|
);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @dataProvider isNotifyTypeDismissableForCategoryProvider
|
|
|
|
*/
|
|
|
|
public function testIsNotifyTypeDismissableForCategory( $message, $expected, $categories, $categoryName, $notifyType ) {
|
|
|
|
$am = new EchoAttributeManager( array(), $categories, array(), array(), array() );
|
|
|
|
$actual = $am->isNotifyTypeDismissableForCategory( $categoryName, $notifyType );
|
|
|
|
$this->assertEquals( $expected, $actual, $message );
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2014-07-22 21:33:22 +00:00
|
|
|
/**
|
|
|
|
* Mock object of User
|
|
|
|
*/
|
|
|
|
protected function mockUser() {
|
|
|
|
$user = $this->getMockBuilder( 'User' )
|
|
|
|
->disableOriginalConstructor()
|
|
|
|
->getMock();
|
|
|
|
$user->expects( $this->any() )
|
|
|
|
->method( 'getID' )
|
|
|
|
->will( $this->returnValue( 1 ) );
|
|
|
|
$user->expects( $this->any() )
|
|
|
|
->method( 'getOption' )
|
|
|
|
->will( $this->returnValue( true ) );
|
|
|
|
$user->expects( $this->any() )
|
|
|
|
->method( 'getGroups' )
|
|
|
|
->will( $this->returnValue( array( 'echo_group' ) ) );
|
2015-10-01 13:48:52 +00:00
|
|
|
|
2014-07-22 21:33:22 +00:00
|
|
|
return $user;
|
|
|
|
}
|
|
|
|
}
|