2014-07-22 21:33:22 +00:00
|
|
|
<?php
|
|
|
|
|
2024-02-22 15:31:00 +00:00
|
|
|
namespace MediaWiki\Extension\Notifications\Test\Unit;
|
|
|
|
|
2022-11-12 07:19:00 +00:00
|
|
|
use MediaWiki\Extension\Notifications\AttributeManager;
|
2023-12-11 15:33:08 +00:00
|
|
|
use MediaWiki\User\Options\UserOptionsLookup;
|
2021-02-25 02:46:03 +00:00
|
|
|
use MediaWiki\User\UserGroupManager;
|
2021-06-29 06:26:58 +00:00
|
|
|
use MediaWiki\User\UserIdentity;
|
|
|
|
use MediaWiki\User\UserIdentityValue;
|
2024-02-22 15:31:00 +00:00
|
|
|
use MediaWikiUnitTestCase;
|
2021-02-25 02:46:03 +00:00
|
|
|
|
2018-01-24 00:31:53 +00:00
|
|
|
/**
|
2022-11-12 07:19:00 +00:00
|
|
|
* @covers \MediaWiki\Extension\Notifications\AttributeManager
|
2018-01-24 00:31:53 +00:00
|
|
|
*/
|
2023-08-12 19:07:15 +00:00
|
|
|
class AttributeManagerTest extends MediaWikiUnitTestCase {
|
2014-07-22 21:33:22 +00:00
|
|
|
|
2021-06-29 06:26:58 +00:00
|
|
|
private function getAttributeManager(
|
|
|
|
array $notifications,
|
|
|
|
array $categories = [],
|
|
|
|
array $defaultNotifyTypeAvailability = [],
|
|
|
|
array $notifyTypeAvailabilityByCategory = []
|
2022-11-12 07:19:00 +00:00
|
|
|
): AttributeManager {
|
2021-06-29 06:26:58 +00:00
|
|
|
$userGroupManager = $this->createNoOpMock( UserGroupManager::class, [ 'getUserGroups' ] );
|
|
|
|
$userGroupManager->method( 'getUserGroups' )->willReturn( [ 'echo_group' ] );
|
|
|
|
|
|
|
|
$userOptionsLookup = $this->createNoOpMock( UserOptionsLookup::class, [ 'getOption' ] );
|
|
|
|
$userOptionsLookup->method( 'getOption' )->willReturn( true );
|
|
|
|
|
2022-11-12 07:19:00 +00:00
|
|
|
return new AttributeManager(
|
2021-06-29 06:26:58 +00:00
|
|
|
$notifications,
|
|
|
|
$categories,
|
|
|
|
$defaultNotifyTypeAvailability,
|
|
|
|
$notifyTypeAvailabilityByCategory,
|
|
|
|
$userGroupManager,
|
|
|
|
$userOptionsLookup
|
|
|
|
);
|
|
|
|
}
|
|
|
|
|
2021-08-11 09:09:55 +00:00
|
|
|
/**
|
|
|
|
* @return UserIdentity
|
|
|
|
*/
|
|
|
|
protected function getUser(): UserIdentity {
|
|
|
|
return new UserIdentityValue( 1, 'ExampleUserName' );
|
|
|
|
}
|
|
|
|
|
2014-07-29 23:54:00 +00:00
|
|
|
public static function getUserLocatorsProvider() {
|
2016-12-05 18:51:07 +00:00
|
|
|
return [
|
|
|
|
[
|
2014-07-29 23:54:00 +00:00
|
|
|
'No errors when requesting unknown type',
|
|
|
|
// expected result
|
2016-12-05 18:51:07 +00:00
|
|
|
[],
|
2014-07-29 23:54:00 +00:00
|
|
|
// event type
|
|
|
|
'foo',
|
|
|
|
// notification configuration
|
2016-12-05 18:51:07 +00:00
|
|
|
[],
|
|
|
|
],
|
2014-07-29 23:54:00 +00:00
|
|
|
|
2016-12-05 18:51:07 +00:00
|
|
|
[
|
2014-07-29 23:54:00 +00:00
|
|
|
'Returns selected notification configuration',
|
|
|
|
// expected result
|
2016-12-05 18:51:07 +00:00
|
|
|
[ 'woot!' ],
|
2014-07-29 23:54:00 +00:00
|
|
|
// event type
|
|
|
|
'magic',
|
|
|
|
// notification configuration
|
2016-12-05 18:51:07 +00:00
|
|
|
[
|
|
|
|
'foo' => [
|
2022-11-12 07:19:00 +00:00
|
|
|
AttributeManager::ATTR_LOCATORS => [ 'frown' ],
|
2016-12-05 18:51:07 +00:00
|
|
|
],
|
|
|
|
'magic' => [
|
2022-11-12 07:19:00 +00:00
|
|
|
AttributeManager::ATTR_LOCATORS => [ 'woot!' ],
|
2016-12-05 18:51:07 +00:00
|
|
|
],
|
|
|
|
],
|
|
|
|
],
|
2014-07-29 23:54:00 +00:00
|
|
|
|
2016-12-05 18:51:07 +00:00
|
|
|
[
|
2014-07-29 23:54:00 +00:00
|
|
|
'Accepts user-locators as string and returns array',
|
|
|
|
// expected result
|
2016-12-05 18:51:07 +00:00
|
|
|
[ 'sagen' ],
|
2014-07-29 23:54:00 +00:00
|
|
|
// event type
|
|
|
|
'challah',
|
|
|
|
// notification configuration
|
2016-12-05 18:51:07 +00:00
|
|
|
[
|
|
|
|
'challah' => [
|
2022-11-12 07:19:00 +00:00
|
|
|
AttributeManager::ATTR_LOCATORS => 'sagen',
|
2016-12-05 18:51:07 +00:00
|
|
|
],
|
|
|
|
],
|
|
|
|
],
|
|
|
|
];
|
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 ) {
|
2021-06-29 06:26:58 +00:00
|
|
|
$manager = $this->getAttributeManager( $notifications );
|
2014-07-29 23:54:00 +00:00
|
|
|
|
2022-11-12 07:19:00 +00:00
|
|
|
$result = $manager->getUserCallable( $type, AttributeManager::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() {
|
2016-12-05 18:51:07 +00:00
|
|
|
$notif = [
|
|
|
|
'event_one' => [
|
2014-07-22 21:33:22 +00:00
|
|
|
'category' => 'category_one'
|
2016-12-05 18:51:07 +00:00
|
|
|
],
|
|
|
|
];
|
|
|
|
$category = [
|
|
|
|
'category_one' => [
|
2014-07-22 21:33:22 +00:00
|
|
|
'priority' => 10
|
2016-12-05 18:51:07 +00:00
|
|
|
]
|
|
|
|
];
|
2021-06-29 06:26:58 +00:00
|
|
|
$manager = $this->getAttributeManager( $notif, $category );
|
|
|
|
$this->assertTrue( $manager->getCategoryEligibility( $this->getUser(), 'category_one' ) );
|
2016-12-05 18:51:07 +00:00
|
|
|
$category = [
|
|
|
|
'category_one' => [
|
2014-07-22 21:33:22 +00:00
|
|
|
'priority' => 10,
|
2016-12-05 18:51:07 +00:00
|
|
|
'usergroups' => [
|
2014-07-22 21:33:22 +00:00
|
|
|
'sysop'
|
2016-12-05 18:51:07 +00:00
|
|
|
]
|
|
|
|
]
|
|
|
|
];
|
2021-06-29 06:26:58 +00:00
|
|
|
$manager = $this->getAttributeManager( $notif, $category );
|
|
|
|
$this->assertFalse( $manager->getCategoryEligibility( $this->getUser(), 'category_one' ) );
|
2014-07-22 21:33:22 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
public function testGetNotificationCategory() {
|
2016-12-05 18:51:07 +00:00
|
|
|
$notif = [
|
|
|
|
'event_one' => [
|
2014-07-22 21:33:22 +00:00
|
|
|
'category' => 'category_one'
|
2016-12-05 18:51:07 +00:00
|
|
|
],
|
|
|
|
];
|
|
|
|
$category = [
|
|
|
|
'category_one' => [
|
2014-07-22 21:33:22 +00:00
|
|
|
'priority' => 10
|
2016-12-05 18:51:07 +00:00
|
|
|
]
|
|
|
|
];
|
2021-06-29 06:26:58 +00:00
|
|
|
$manager = $this->getAttributeManager( $notif, $category );
|
2021-10-23 21:59:04 +00:00
|
|
|
$this->assertEquals( 'category_one', $manager->getNotificationCategory( 'event_one' ) );
|
2014-07-22 21:33:22 +00:00
|
|
|
|
2021-06-29 06:26:58 +00:00
|
|
|
$manager = $this->getAttributeManager( $notif );
|
2021-10-23 21:59:04 +00:00
|
|
|
$this->assertEquals( 'other', $manager->getNotificationCategory( 'event_one' ) );
|
2014-07-22 21:33:22 +00:00
|
|
|
|
2016-12-05 18:51:07 +00:00
|
|
|
$notif = [
|
|
|
|
'event_one' => [
|
2014-07-22 21:33:22 +00:00
|
|
|
'category' => 'category_two'
|
2016-12-05 18:51:07 +00:00
|
|
|
],
|
|
|
|
];
|
|
|
|
$category = [
|
|
|
|
'category_one' => [
|
2014-07-22 21:33:22 +00:00
|
|
|
'priority' => 10
|
2016-12-05 18:51:07 +00:00
|
|
|
]
|
|
|
|
];
|
2021-06-29 06:26:58 +00:00
|
|
|
$manager = $this->getAttributeManager( $notif, $category );
|
2021-10-23 21:59:04 +00:00
|
|
|
$this->assertEquals( 'other', $manager->getNotificationCategory( 'event_one' ) );
|
2014-07-22 21:33:22 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
public function testGetCategoryPriority() {
|
2016-12-05 18:51:07 +00:00
|
|
|
$notif = [
|
|
|
|
'event_one' => [
|
2014-07-22 21:33:22 +00:00
|
|
|
'category' => 'category_two'
|
2016-12-05 18:51:07 +00:00
|
|
|
],
|
|
|
|
];
|
|
|
|
$category = [
|
|
|
|
'category_one' => [
|
2014-07-22 21:33:22 +00:00
|
|
|
'priority' => 6
|
2016-12-05 18:51:07 +00:00
|
|
|
],
|
|
|
|
'category_two' => [
|
2014-07-22 21:33:22 +00:00
|
|
|
'priority' => 100
|
2016-12-05 18:51:07 +00:00
|
|
|
],
|
|
|
|
'category_three' => [
|
2014-07-22 21:33:22 +00:00
|
|
|
'priority' => -10
|
2016-12-05 18:51:07 +00:00
|
|
|
],
|
|
|
|
'category_four' => []
|
|
|
|
];
|
2021-06-29 06:26:58 +00:00
|
|
|
$manager = $this->getAttributeManager( $notif, $category );
|
2019-10-23 10:28:30 +00:00
|
|
|
$this->assertSame( 6, $manager->getCategoryPriority( 'category_one' ) );
|
|
|
|
$this->assertSame( 10, $manager->getCategoryPriority( 'category_two' ) );
|
|
|
|
$this->assertSame( 10, $manager->getCategoryPriority( 'category_three' ) );
|
|
|
|
$this->assertSame( 10, $manager->getCategoryPriority( 'category_four' ) );
|
2014-07-22 21:33:22 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
public function testGetNotificationPriority() {
|
2016-12-05 18:51:07 +00:00
|
|
|
$notif = [
|
|
|
|
'event_one' => [
|
2014-07-22 21:33:22 +00:00
|
|
|
'category' => 'category_one'
|
2016-12-05 18:51:07 +00:00
|
|
|
],
|
|
|
|
'event_two' => [
|
2014-07-22 21:33:22 +00:00
|
|
|
'category' => 'category_two'
|
2016-12-05 18:51:07 +00:00
|
|
|
],
|
|
|
|
'event_three' => [
|
2014-07-22 21:33:22 +00:00
|
|
|
'category' => 'category_three'
|
2016-12-05 18:51:07 +00:00
|
|
|
],
|
|
|
|
'event_four' => [
|
2014-07-22 21:33:22 +00:00
|
|
|
'category' => 'category_four'
|
2016-12-05 18:51:07 +00:00
|
|
|
]
|
|
|
|
];
|
|
|
|
$category = [
|
|
|
|
'category_one' => [
|
2014-07-22 21:33:22 +00:00
|
|
|
'priority' => 6
|
2016-12-05 18:51:07 +00:00
|
|
|
],
|
|
|
|
'category_two' => [
|
2014-07-22 21:33:22 +00:00
|
|
|
'priority' => 100
|
2016-12-05 18:51:07 +00:00
|
|
|
],
|
|
|
|
'category_three' => [
|
2014-07-22 21:33:22 +00:00
|
|
|
'priority' => -10
|
2016-12-05 18:51:07 +00:00
|
|
|
],
|
|
|
|
'category_four' => []
|
|
|
|
];
|
2021-06-29 06:26:58 +00:00
|
|
|
$manager = $this->getAttributeManager( $notif, $category );
|
2019-10-23 10:28:30 +00:00
|
|
|
$this->assertSame( 6, $manager->getNotificationPriority( 'event_one' ) );
|
|
|
|
$this->assertSame( 10, $manager->getNotificationPriority( 'event_two' ) );
|
|
|
|
$this->assertSame( 10, $manager->getNotificationPriority( 'event_three' ) );
|
|
|
|
$this->assertSame( 10, $manager->getNotificationPriority( 'event_four' ) );
|
2014-07-22 21:33:22 +00:00
|
|
|
}
|
|
|
|
|
2016-04-27 21:43:00 +00:00
|
|
|
public static function getEventsForSectionProvider() {
|
2016-12-05 18:51:07 +00:00
|
|
|
$notifications = [
|
|
|
|
'event_one' => [
|
2014-08-05 21:50:54 +00:00
|
|
|
'category' => 'category_one',
|
2016-04-27 21:43:00 +00:00
|
|
|
'section' => 'message',
|
2016-12-05 18:51:07 +00:00
|
|
|
],
|
|
|
|
'event_two' => [
|
2016-04-27 21:43:00 +00:00
|
|
|
'category' => 'category_two',
|
|
|
|
'section' => 'invalid',
|
2016-12-05 18:51:07 +00:00
|
|
|
],
|
|
|
|
'event_three' => [
|
2014-08-05 21:50:54 +00:00
|
|
|
'category' => 'category_three',
|
2016-04-27 21:43:00 +00:00
|
|
|
'section' => 'message',
|
2016-12-05 18:51:07 +00:00
|
|
|
],
|
|
|
|
'event_four' => [
|
2016-04-27 21:43:00 +00:00
|
|
|
'category' => 'category_four',
|
|
|
|
// Omitted
|
2016-12-05 18:51:07 +00:00
|
|
|
],
|
|
|
|
'event_five' => [
|
2016-04-27 21:43:00 +00:00
|
|
|
'category' => 'category_two',
|
|
|
|
'section' => 'alert',
|
2016-12-05 18:51:07 +00:00
|
|
|
],
|
|
|
|
];
|
2014-08-05 21:50:54 +00:00
|
|
|
|
2016-12-05 18:51:07 +00:00
|
|
|
return [
|
|
|
|
[
|
|
|
|
[ 'event_one', 'event_three' ],
|
2016-04-27 21:43:00 +00:00
|
|
|
$notifications,
|
|
|
|
'message',
|
|
|
|
'Messages',
|
2016-12-05 18:51:07 +00:00
|
|
|
],
|
2016-04-27 21:43:00 +00:00
|
|
|
|
2016-12-05 18:51:07 +00:00
|
|
|
[
|
|
|
|
[ 'event_two', 'event_four', 'event_five' ],
|
2016-04-27 21:43:00 +00:00
|
|
|
$notifications,
|
|
|
|
'alert',
|
|
|
|
'Alerts',
|
2016-12-05 18:51:07 +00:00
|
|
|
],
|
|
|
|
];
|
2016-04-27 21:43:00 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @dataProvider getEventsForSectionProvider
|
|
|
|
*/
|
|
|
|
public function testGetEventsForSection( $expected, $notificationTypes, $section, $message ) {
|
2021-06-29 06:26:58 +00:00
|
|
|
$am = $this->getAttributeManager( $notificationTypes );
|
2016-04-27 21:43:00 +00:00
|
|
|
$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() {
|
2016-12-05 18:51:07 +00:00
|
|
|
$notif = [
|
|
|
|
'event_one' => [
|
2014-07-22 21:33:22 +00:00
|
|
|
'category' => 'category_one'
|
2016-12-05 18:51:07 +00:00
|
|
|
],
|
|
|
|
'event_two' => [
|
2014-07-22 21:33:22 +00:00
|
|
|
'category' => 'category_two'
|
2016-12-05 18:51:07 +00:00
|
|
|
],
|
|
|
|
'event_three' => [
|
2014-07-22 21:33:22 +00:00
|
|
|
'category' => 'category_three'
|
2016-12-05 18:51:07 +00:00
|
|
|
],
|
2019-04-12 22:34:28 +00:00
|
|
|
'event_four' => [
|
|
|
|
'category' => 'category_four'
|
|
|
|
]
|
2016-12-05 18:51:07 +00:00
|
|
|
];
|
|
|
|
$category = [
|
|
|
|
'category_one' => [
|
2014-07-22 21:33:22 +00:00
|
|
|
'priority' => 10,
|
2016-12-05 18:51:07 +00:00
|
|
|
'usergroups' => [
|
2014-07-22 21:33:22 +00:00
|
|
|
'sysop'
|
2016-12-05 18:51:07 +00:00
|
|
|
]
|
|
|
|
],
|
|
|
|
'category_two' => [
|
2014-07-22 21:33:22 +00:00
|
|
|
'priority' => 10,
|
2016-12-05 18:51:07 +00:00
|
|
|
'usergroups' => [
|
2014-07-22 21:33:22 +00:00
|
|
|
'echo_group'
|
2016-12-05 18:51:07 +00:00
|
|
|
]
|
|
|
|
],
|
|
|
|
'category_three' => [
|
2014-07-22 21:33:22 +00:00
|
|
|
'priority' => 10,
|
2016-12-05 18:51:07 +00:00
|
|
|
],
|
2019-04-12 22:34:28 +00:00
|
|
|
'category_four' => [
|
|
|
|
'priority' => 10,
|
|
|
|
]
|
2016-12-05 18:51:07 +00:00
|
|
|
];
|
2019-04-12 22:34:28 +00:00
|
|
|
$defaultNotifyTypeAvailability = [
|
|
|
|
'web' => true,
|
|
|
|
'email' => true,
|
|
|
|
];
|
|
|
|
$notifyTypeAvailabilityByCategory = [
|
|
|
|
'category_three' => [
|
|
|
|
'web' => false,
|
|
|
|
'email' => true,
|
|
|
|
]
|
|
|
|
];
|
2021-06-29 06:26:58 +00:00
|
|
|
$manager = $this->getAttributeManager(
|
2020-06-27 10:05:03 +00:00
|
|
|
$notif,
|
|
|
|
$category,
|
|
|
|
$defaultNotifyTypeAvailability,
|
2021-06-29 06:26:58 +00:00
|
|
|
$notifyTypeAvailabilityByCategory
|
2020-06-27 10:05:03 +00:00
|
|
|
);
|
|
|
|
$this->assertEquals(
|
|
|
|
[ 'event_two', 'event_four' ],
|
2021-06-29 06:26:58 +00:00
|
|
|
$manager->getUserEnabledEvents( $this->getUser(), 'web' )
|
2020-06-27 10:05:03 +00:00
|
|
|
);
|
2021-08-13 15:53:55 +00:00
|
|
|
$this->assertEquals(
|
|
|
|
[ 'event_two', 'event_three', 'event_four' ],
|
|
|
|
$manager->getUserEnabledEvents( $this->getUser(), [ 'web', 'email' ] )
|
|
|
|
);
|
2014-07-22 21:33:22 +00:00
|
|
|
}
|
|
|
|
|
2021-08-20 16:54:38 +00:00
|
|
|
public function testGetUserEnabledEventsBySections() {
|
2016-12-05 18:51:07 +00:00
|
|
|
$notif = [
|
|
|
|
'event_one' => [
|
2014-08-05 21:50:54 +00:00
|
|
|
'category' => 'category_one'
|
2016-12-05 18:51:07 +00:00
|
|
|
],
|
|
|
|
'event_two' => [
|
2014-08-05 21:50:54 +00:00
|
|
|
'category' => 'category_two',
|
|
|
|
'section' => 'message'
|
2016-12-05 18:51:07 +00:00
|
|
|
],
|
|
|
|
'event_three' => [
|
2014-08-05 21:50:54 +00:00
|
|
|
'category' => 'category_three',
|
|
|
|
'section' => 'alert'
|
2016-12-05 18:51:07 +00:00
|
|
|
],
|
|
|
|
'event_four' => [
|
2014-08-05 21:50:54 +00:00
|
|
|
'category' => 'category_three',
|
2016-12-05 18:51:07 +00:00
|
|
|
],
|
2019-04-12 22:34:28 +00:00
|
|
|
'event_five' => [
|
|
|
|
'category' => 'category_five'
|
|
|
|
]
|
2016-12-05 18:51:07 +00:00
|
|
|
];
|
|
|
|
$category = [
|
|
|
|
'category_one' => [
|
2014-08-05 21:50:54 +00:00
|
|
|
'priority' => 10,
|
2016-12-05 18:51:07 +00:00
|
|
|
],
|
|
|
|
'category_two' => [
|
2014-08-05 21:50:54 +00:00
|
|
|
'priority' => 10,
|
2016-12-05 18:51:07 +00:00
|
|
|
],
|
|
|
|
'category_three' => [
|
2014-08-05 21:50:54 +00:00
|
|
|
'priority' => 10
|
2016-12-05 18:51:07 +00:00
|
|
|
],
|
2019-04-12 22:34:28 +00:00
|
|
|
'category_five' => [
|
|
|
|
'priority' => 10
|
|
|
|
]
|
2016-12-05 18:51:07 +00:00
|
|
|
];
|
2019-04-12 22:34:28 +00:00
|
|
|
$defaultNotifyTypeAvailability = [
|
|
|
|
'web' => true,
|
|
|
|
'email' => true,
|
|
|
|
];
|
|
|
|
$notifyTypeAvailabilityByCategory = [
|
|
|
|
'category_five' => [
|
|
|
|
'web' => false,
|
|
|
|
'email' => true,
|
|
|
|
]
|
|
|
|
];
|
2021-06-29 06:26:58 +00:00
|
|
|
$manager = $this->getAttributeManager(
|
2020-06-27 10:05:03 +00:00
|
|
|
$notif,
|
|
|
|
$category,
|
|
|
|
$defaultNotifyTypeAvailability,
|
2021-06-29 06:26:58 +00:00
|
|
|
$notifyTypeAvailabilityByCategory
|
2020-06-27 10:05:03 +00:00
|
|
|
);
|
2016-12-05 18:51:07 +00:00
|
|
|
$expected = [ 'event_one', 'event_three', 'event_four' ];
|
2021-08-20 16:54:38 +00:00
|
|
|
$actual = $manager->getUserEnabledEventsBySections( $this->getUser(), 'web', [ 'alert' ] );
|
2014-08-05 21:50:54 +00:00
|
|
|
sort( $expected );
|
|
|
|
sort( $actual );
|
2019-04-12 22:34:28 +00:00
|
|
|
$this->assertEquals( $expected, $actual );
|
2014-08-05 21:50:54 +00:00
|
|
|
|
2021-08-13 15:53:55 +00:00
|
|
|
$expected = [ 'event_one', 'event_three', 'event_four', 'event_five' ];
|
2021-08-20 16:54:38 +00:00
|
|
|
$actual = $manager->getUserEnabledEventsBySections( $this->getUser(), [ 'web', 'email' ], [ 'alert' ] );
|
2021-08-13 15:53:55 +00:00
|
|
|
sort( $expected );
|
|
|
|
sort( $actual );
|
|
|
|
$this->assertEquals( $expected, $actual );
|
|
|
|
|
2016-12-05 18:51:07 +00:00
|
|
|
$expected = [ 'event_two' ];
|
2021-08-20 16:54:38 +00:00
|
|
|
$actual = $manager->getUserEnabledEventsBySections( $this->getUser(), 'web', [ 'message' ] );
|
2014-08-05 21:50:54 +00:00
|
|
|
sort( $expected );
|
|
|
|
sort( $actual );
|
2019-04-12 22:34:28 +00:00
|
|
|
$this->assertEquals( $expected, $actual );
|
2014-08-05 21:50:54 +00:00
|
|
|
|
2016-12-05 18:51:07 +00:00
|
|
|
$expected = [ 'event_one', 'event_two', 'event_three', 'event_four' ];
|
2021-08-20 16:54:38 +00:00
|
|
|
$actual = $manager->getUserEnabledEventsBySections( $this->getUser(), 'web',
|
2018-08-25 10:51:14 +00:00
|
|
|
[ 'message', 'alert' ] );
|
2014-08-05 21:50:54 +00:00
|
|
|
sort( $expected );
|
|
|
|
sort( $actual );
|
2019-04-12 22:34:28 +00:00
|
|
|
$this->assertEquals( $expected, $actual );
|
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
|
|
|
public static function getEventsByCategoryProvider() {
|
2016-12-05 18:51:07 +00:00
|
|
|
return [
|
|
|
|
[
|
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
|
|
|
'Mix of populated and empty categories handled appropriately',
|
2016-12-05 18:51:07 +00:00
|
|
|
[
|
|
|
|
'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
|
|
|
'event_two',
|
|
|
|
'event_five',
|
2016-12-05 18:51:07 +00:00
|
|
|
],
|
|
|
|
'category_two' => [
|
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
|
|
|
'event_one',
|
|
|
|
'event_three',
|
|
|
|
'event_four',
|
2016-12-05 18:51:07 +00:00
|
|
|
],
|
|
|
|
'category_three' => [],
|
|
|
|
],
|
|
|
|
[
|
|
|
|
'category_one' => [],
|
|
|
|
'category_two' => [],
|
|
|
|
'category_three' => [],
|
|
|
|
],
|
|
|
|
[
|
|
|
|
'event_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
|
|
|
'category' => 'category_two',
|
2016-12-05 18:51:07 +00:00
|
|
|
],
|
|
|
|
'event_two' => [
|
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
|
|
|
'category' => 'category_one',
|
2016-12-05 18:51:07 +00:00
|
|
|
],
|
|
|
|
'event_three' => [
|
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
|
|
|
'category' => 'category_two',
|
2016-12-05 18:51:07 +00:00
|
|
|
],
|
|
|
|
'event_four' => [
|
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
|
|
|
'category' => 'category_two',
|
2016-12-05 18:51:07 +00:00
|
|
|
],
|
|
|
|
'event_five' => [
|
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
|
|
|
'category' => 'category_one',
|
2016-12-05 18:51:07 +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
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @dataProvider getEventsByCategoryProvider
|
|
|
|
*/
|
2018-08-25 10:51:14 +00:00
|
|
|
public function testGetEventsByCategory(
|
|
|
|
$message,
|
|
|
|
$expectedMapping,
|
|
|
|
$categories,
|
|
|
|
$notifications
|
|
|
|
) {
|
2021-06-29 06:26:58 +00:00
|
|
|
$am = $this->getAttributeManager( $notifications, $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
|
|
|
$actualMapping = $am->getEventsByCategory();
|
|
|
|
$this->assertEquals( $expectedMapping, $actualMapping, $message );
|
|
|
|
}
|
|
|
|
|
|
|
|
public static function isNotifyTypeAvailableForCategoryProvider() {
|
2016-12-05 18:51:07 +00:00
|
|
|
return [
|
|
|
|
[
|
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
|
|
|
'Fallback to default entirely',
|
|
|
|
true,
|
|
|
|
'category_one',
|
|
|
|
'web',
|
2016-12-05 18:51:07 +00:00
|
|
|
[ 'web' => true, 'email' => true ],
|
|
|
|
[]
|
|
|
|
],
|
|
|
|
[
|
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
|
|
|
'Fallback to default for single type',
|
|
|
|
false,
|
|
|
|
'category_two',
|
|
|
|
'email',
|
2016-12-05 18:51:07 +00:00
|
|
|
[ 'web' => true, 'email' => false ],
|
|
|
|
[
|
|
|
|
'category_two' => [
|
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
|
|
|
'web' => true,
|
2016-12-05 18:51:07 +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
|
|
|
'Use override',
|
|
|
|
false,
|
|
|
|
'category_three',
|
|
|
|
'web',
|
2016-12-05 18:51:07 +00:00
|
|
|
[ 'web' => true, 'email' => true ],
|
|
|
|
[
|
|
|
|
'category_three' => [
|
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
|
|
|
'web' => false,
|
2016-12-05 18:51:07 +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
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2020-01-14 05:09:42 +00:00
|
|
|
* @dataProvider isNotifyTypeAvailableForCategoryProvider
|
|
|
|
*/
|
2018-08-25 10:51:14 +00:00
|
|
|
public function testIsNotifyTypeAvailableForCategory(
|
|
|
|
$message,
|
|
|
|
$expected,
|
|
|
|
$categoryName,
|
|
|
|
$notifyType,
|
|
|
|
$defaultNotifyTypeAvailability,
|
|
|
|
$notifyTypeAvailabilityByCategory
|
|
|
|
) {
|
2021-06-29 06:26:58 +00:00
|
|
|
$am = $this->getAttributeManager(
|
|
|
|
[],
|
|
|
|
[],
|
|
|
|
$defaultNotifyTypeAvailability,
|
|
|
|
$notifyTypeAvailabilityByCategory
|
|
|
|
);
|
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
|
|
|
$actual = $am->isNotifyTypeAvailableForCategory( $categoryName, $notifyType );
|
|
|
|
$this->assertEquals( $expected, $actual, $message );
|
|
|
|
}
|
|
|
|
|
|
|
|
public static function isNotifyTypeDismissableForCategoryProvider() {
|
2016-12-05 18:51:07 +00:00
|
|
|
return [
|
|
|
|
[
|
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
|
|
|
'Not dismissable because of all',
|
|
|
|
false,
|
2016-12-05 18:51:07 +00:00
|
|
|
[
|
|
|
|
'category_one' => [
|
|
|
|
'no-dismiss' => [ 'all' ],
|
|
|
|
]
|
|
|
|
],
|
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
|
|
|
'category_one',
|
|
|
|
'web',
|
2016-12-05 18:51:07 +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
|
|
|
'Not dismissable because of specific notify type',
|
|
|
|
false,
|
2016-12-05 18:51:07 +00:00
|
|
|
[
|
|
|
|
'category_two' => [
|
|
|
|
'no-dismiss' => [ 'email' ],
|
|
|
|
]
|
|
|
|
],
|
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
|
|
|
'category_two',
|
|
|
|
'email',
|
2016-12-05 18:51:07 +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
|
|
|
'Dismissable because of different affected notify type',
|
|
|
|
true,
|
2016-12-05 18:51:07 +00:00
|
|
|
[
|
|
|
|
'category_three' => [
|
|
|
|
'no-dismiss' => [ 'web' ],
|
|
|
|
]
|
|
|
|
],
|
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
|
|
|
'category_three',
|
|
|
|
'email',
|
2016-12-05 18:51:07 +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
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @dataProvider isNotifyTypeDismissableForCategoryProvider
|
|
|
|
*/
|
2018-08-25 10:51:14 +00:00
|
|
|
public function testIsNotifyTypeDismissableForCategory(
|
|
|
|
$message,
|
|
|
|
$expected,
|
|
|
|
$categories,
|
|
|
|
$categoryName,
|
|
|
|
$notifyType
|
|
|
|
) {
|
2021-06-29 06:26:58 +00:00
|
|
|
$am = $this->getAttributeManager( [], $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
|
|
|
$actual = $am->isNotifyTypeDismissableForCategory( $categoryName, $notifyType );
|
|
|
|
$this->assertEquals( $expected, $actual, $message );
|
|
|
|
}
|
|
|
|
|
2023-05-20 18:35:53 +00:00
|
|
|
public static function getNotificationSectionProvider() {
|
2021-08-11 09:09:55 +00:00
|
|
|
yield [ 'event_one', 'alert' ];
|
|
|
|
yield [ 'event_two', 'message' ];
|
|
|
|
yield [ 'event_three', 'alert' ];
|
|
|
|
yield [ 'event_undefined', 'alert' ];
|
|
|
|
}
|
|
|
|
|
2014-07-22 21:33:22 +00:00
|
|
|
/**
|
2021-08-11 09:09:55 +00:00
|
|
|
* @dataProvider getNotificationSectionProvider
|
2014-07-22 21:33:22 +00:00
|
|
|
*/
|
2021-08-11 09:09:55 +00:00
|
|
|
public function testGetNotificationSection( $type, $expected ) {
|
|
|
|
$am = $this->getAttributeManager( [
|
|
|
|
'event_one' => [
|
|
|
|
'section' => 'alert',
|
|
|
|
],
|
|
|
|
'event_two' => [
|
|
|
|
'section' => 'message',
|
|
|
|
],
|
|
|
|
'event_three' => [],
|
|
|
|
] );
|
|
|
|
$actual = $am->getNotificationSection( $type );
|
|
|
|
$this->assertSame( $expected, $actual );
|
2021-02-25 02:46:03 +00:00
|
|
|
}
|
2021-08-11 09:09:55 +00:00
|
|
|
|
2023-05-20 18:35:53 +00:00
|
|
|
public static function isBundleExpandableProvider() {
|
2021-08-11 09:22:49 +00:00
|
|
|
yield [ 'event_one', false ];
|
|
|
|
yield [ 'event_two', false ];
|
|
|
|
yield [ 'event_three', false ];
|
|
|
|
yield [ 'event_four', true ];
|
|
|
|
yield [ 'event_undefined', false ];
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @dataProvider isBundleExpandableProvider
|
|
|
|
*/
|
|
|
|
public function testIsBundleExpandable( $type, $expected ) {
|
|
|
|
$am = $this->getAttributeManager( [
|
|
|
|
'event_one' => [],
|
|
|
|
'event_two' => [
|
|
|
|
'bundle' => [
|
|
|
|
'web' => true
|
|
|
|
]
|
|
|
|
],
|
|
|
|
'event_three' => [
|
|
|
|
'bundle' => [
|
|
|
|
'web' => true,
|
|
|
|
'email' => false,
|
|
|
|
'expandable' => false
|
|
|
|
]
|
|
|
|
],
|
|
|
|
'event_four' => [
|
|
|
|
'bundle' => [
|
|
|
|
'web' => true,
|
|
|
|
'email' => true,
|
|
|
|
'expandable' => true
|
|
|
|
]
|
|
|
|
],
|
|
|
|
] );
|
|
|
|
$actual = $am->isBundleExpandable( $type );
|
|
|
|
$this->assertSame( $expected, $actual );
|
|
|
|
}
|
|
|
|
|
2014-07-22 21:33:22 +00:00
|
|
|
}
|