Thijs/wiki.techinc.nl
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
wiki.techinc.nl/tests/phpunit/includes/user/DefaultOptionsLookupTest.php

57 lines
1.8 KiB
PHP
Raw Normal View History

Introduce UserOptionsManager and DefaultOptionsManager This converts user options management to a separate service for use in DI context. User options are accessed quite early on in installation process and full-on options management depends on the database. Prior we have protected from accessing the DB by setting a hacky $wgUser with 0 id, and relying on the implementation that it doesn't go into the database to get the default user options. Now we can't really do that since DBLoadBalancer is required to instantiate the options manager. Instead, we redefine the options manager with a DefaultOptionsManager, that only provides access to default options and doesn't require DB access. UserOptionsManager uses PreferencesFactory, however injecting it will produce a cyclic dependency. The problem is that we separate options to different kinds, which are inferred from the PreferencesFactory declaration for those options (e.g. if it's a radio button in the UI declaration, the option is of multiselect kind). This is plain wrong, the dependency should be wise versa. This will be addressed separately, since it's requires larger refactoring. For now the PreferencesFactory is obtained on demand. This will be addressed in a followup. Bug: T248527 Change-Id: I74917c5eaec184d188911a319895b941ed55ee87
2020-01-17 06:21:28 +00:00
<?php
Rename DefaultOptionsManager to DefaultOptionsLookup This is not really a manager, since it only supports reading defaul options. Inroduced in 1.35 and not yet used outside of core, so no deprecations are needed. Change-Id: If67af54574d9c2e44ed85d1bdd098afd0a21e8f9
2020-05-11 19:19:13 +00:00
use MediaWiki\User\DefaultOptionsLookup;
Introduce UserOptionsManager and DefaultOptionsManager This converts user options management to a separate service for use in DI context. User options are accessed quite early on in installation process and full-on options management depends on the database. Prior we have protected from accessing the DB by setting a hacky $wgUser with 0 id, and relying on the implementation that it doesn't go into the database to get the default user options. Now we can't really do that since DBLoadBalancer is required to instantiate the options manager. Instead, we redefine the options manager with a DefaultOptionsManager, that only provides access to default options and doesn't require DB access. UserOptionsManager uses PreferencesFactory, however injecting it will produce a cyclic dependency. The problem is that we separate options to different kinds, which are inferred from the PreferencesFactory declaration for those options (e.g. if it's a radio button in the UI declaration, the option is of multiselect kind). This is plain wrong, the dependency should be wise versa. This will be addressed separately, since it's requires larger refactoring. For now the PreferencesFactory is obtained on demand. This will be addressed in a followup. Bug: T248527 Change-Id: I74917c5eaec184d188911a319895b941ed55ee87
2020-01-17 06:21:28 +00:00
use MediaWiki\User\UserOptionsLookup;
/**
Rename DefaultOptionsManager to DefaultOptionsLookup This is not really a manager, since it only supports reading defaul options. Inroduced in 1.35 and not yet used outside of core, so no deprecations are needed. Change-Id: If67af54574d9c2e44ed85d1bdd098afd0a21e8f9
2020-05-11 19:19:13 +00:00
* @covers MediaWiki\User\DefaultOptionsLookup
Introduce UserOptionsManager and DefaultOptionsManager This converts user options management to a separate service for use in DI context. User options are accessed quite early on in installation process and full-on options management depends on the database. Prior we have protected from accessing the DB by setting a hacky $wgUser with 0 id, and relying on the implementation that it doesn't go into the database to get the default user options. Now we can't really do that since DBLoadBalancer is required to instantiate the options manager. Instead, we redefine the options manager with a DefaultOptionsManager, that only provides access to default options and doesn't require DB access. UserOptionsManager uses PreferencesFactory, however injecting it will produce a cyclic dependency. The problem is that we separate options to different kinds, which are inferred from the PreferencesFactory declaration for those options (e.g. if it's a radio button in the UI declaration, the option is of multiselect kind). This is plain wrong, the dependency should be wise versa. This will be addressed separately, since it's requires larger refactoring. For now the PreferencesFactory is obtained on demand. This will be addressed in a followup. Bug: T248527 Change-Id: I74917c5eaec184d188911a319895b941ed55ee87
2020-01-17 06:21:28 +00:00
*/
Rename DefaultOptionsManager to DefaultOptionsLookup This is not really a manager, since it only supports reading defaul options. Inroduced in 1.35 and not yet used outside of core, so no deprecations are needed. Change-Id: If67af54574d9c2e44ed85d1bdd098afd0a21e8f9
2020-05-11 19:19:13 +00:00
class DefaultOptionsLookupTest extends UserOptionsLookupTest {
Introduce UserOptionsManager and DefaultOptionsManager This converts user options management to a separate service for use in DI context. User options are accessed quite early on in installation process and full-on options management depends on the database. Prior we have protected from accessing the DB by setting a hacky $wgUser with 0 id, and relying on the implementation that it doesn't go into the database to get the default user options. Now we can't really do that since DBLoadBalancer is required to instantiate the options manager. Instead, we redefine the options manager with a DefaultOptionsManager, that only provides access to default options and doesn't require DB access. UserOptionsManager uses PreferencesFactory, however injecting it will produce a cyclic dependency. The problem is that we separate options to different kinds, which are inferred from the PreferencesFactory declaration for those options (e.g. if it's a radio button in the UI declaration, the option is of multiselect kind). This is plain wrong, the dependency should be wise versa. This will be addressed separately, since it's requires larger refactoring. For now the PreferencesFactory is obtained on demand. This will be addressed in a followup. Bug: T248527 Change-Id: I74917c5eaec184d188911a319895b941ed55ee87
2020-01-17 06:21:28 +00:00
protected function getLookup(
string $langCode = 'qqq',
array $defaultOptionsOverrides = []
build: Updating dependencies composer: * mediawiki/mediawiki-codesniffer: 36.0.0 → 37.0.0 The following sniffs now pass and were enabled: * Generic.ControlStructures.InlineControlStructure * MediaWiki.PHPUnit.AssertCount.NotUsed npm: * svgo: 2.3.0 → 2.3.1 * https://npmjs.com/advisories/1754 (CVE-2021-33587) Change-Id: I2a9bbee2fecbf7259876d335f565ece4b3622426
2021-07-22 03:11:47 +00:00
): UserOptionsLookup {
Introduce UserOptionsManager and DefaultOptionsManager This converts user options management to a separate service for use in DI context. User options are accessed quite early on in installation process and full-on options management depends on the database. Prior we have protected from accessing the DB by setting a hacky $wgUser with 0 id, and relying on the implementation that it doesn't go into the database to get the default user options. Now we can't really do that since DBLoadBalancer is required to instantiate the options manager. Instead, we redefine the options manager with a DefaultOptionsManager, that only provides access to default options and doesn't require DB access. UserOptionsManager uses PreferencesFactory, however injecting it will produce a cyclic dependency. The problem is that we separate options to different kinds, which are inferred from the PreferencesFactory declaration for those options (e.g. if it's a radio button in the UI declaration, the option is of multiselect kind). This is plain wrong, the dependency should be wise versa. This will be addressed separately, since it's requires larger refactoring. For now the PreferencesFactory is obtained on demand. This will be addressed in a followup. Bug: T248527 Change-Id: I74917c5eaec184d188911a319895b941ed55ee87
2020-01-17 06:21:28 +00:00
return $this->getDefaultManager( $langCode, $defaultOptionsOverrides );
}
/**
Rename DefaultOptionsManager to DefaultOptionsLookup This is not really a manager, since it only supports reading defaul options. Inroduced in 1.35 and not yet used outside of core, so no deprecations are needed. Change-Id: If67af54574d9c2e44ed85d1bdd098afd0a21e8f9
2020-05-11 19:19:13 +00:00
* @covers MediaWiki\User\DefaultOptionsLookup::getOption
Introduce UserOptionsManager and DefaultOptionsManager This converts user options management to a separate service for use in DI context. User options are accessed quite early on in installation process and full-on options management depends on the database. Prior we have protected from accessing the DB by setting a hacky $wgUser with 0 id, and relying on the implementation that it doesn't go into the database to get the default user options. Now we can't really do that since DBLoadBalancer is required to instantiate the options manager. Instead, we redefine the options manager with a DefaultOptionsManager, that only provides access to default options and doesn't require DB access. UserOptionsManager uses PreferencesFactory, however injecting it will produce a cyclic dependency. The problem is that we separate options to different kinds, which are inferred from the PreferencesFactory declaration for those options (e.g. if it's a radio button in the UI declaration, the option is of multiselect kind). This is plain wrong, the dependency should be wise versa. This will be addressed separately, since it's requires larger refactoring. For now the PreferencesFactory is obtained on demand. This will be addressed in a followup. Bug: T248527 Change-Id: I74917c5eaec184d188911a319895b941ed55ee87
2020-01-17 06:21:28 +00:00
*/
public function testGetOptionsExcludeDefaults() {
$this->assertSame( [], $this->getLookup()
Rename DefaultOptionsManager to DefaultOptionsLookup This is not really a manager, since it only supports reading defaul options. Inroduced in 1.35 and not yet used outside of core, so no deprecations are needed. Change-Id: If67af54574d9c2e44ed85d1bdd098afd0a21e8f9
2020-05-11 19:19:13 +00:00
->getOptions( $this->getAnon(), DefaultOptionsLookup::EXCLUDE_DEFAULTS ) );
Introduce UserOptionsManager and DefaultOptionsManager This converts user options management to a separate service for use in DI context. User options are accessed quite early on in installation process and full-on options management depends on the database. Prior we have protected from accessing the DB by setting a hacky $wgUser with 0 id, and relying on the implementation that it doesn't go into the database to get the default user options. Now we can't really do that since DBLoadBalancer is required to instantiate the options manager. Instead, we redefine the options manager with a DefaultOptionsManager, that only provides access to default options and doesn't require DB access. UserOptionsManager uses PreferencesFactory, however injecting it will produce a cyclic dependency. The problem is that we separate options to different kinds, which are inferred from the PreferencesFactory declaration for those options (e.g. if it's a radio button in the UI declaration, the option is of multiselect kind). This is plain wrong, the dependency should be wise versa. This will be addressed separately, since it's requires larger refactoring. For now the PreferencesFactory is obtained on demand. This will be addressed in a followup. Bug: T248527 Change-Id: I74917c5eaec184d188911a319895b941ed55ee87
2020-01-17 06:21:28 +00:00
}
/**
Rename DefaultOptionsManager to DefaultOptionsLookup This is not really a manager, since it only supports reading defaul options. Inroduced in 1.35 and not yet used outside of core, so no deprecations are needed. Change-Id: If67af54574d9c2e44ed85d1bdd098afd0a21e8f9
2020-05-11 19:19:13 +00:00
* @covers MediaWiki\User\DefaultOptionsLookup::getDefaultOptions
Introduce UserOptionsManager and DefaultOptionsManager This converts user options management to a separate service for use in DI context. User options are accessed quite early on in installation process and full-on options management depends on the database. Prior we have protected from accessing the DB by setting a hacky $wgUser with 0 id, and relying on the implementation that it doesn't go into the database to get the default user options. Now we can't really do that since DBLoadBalancer is required to instantiate the options manager. Instead, we redefine the options manager with a DefaultOptionsManager, that only provides access to default options and doesn't require DB access. UserOptionsManager uses PreferencesFactory, however injecting it will produce a cyclic dependency. The problem is that we separate options to different kinds, which are inferred from the PreferencesFactory declaration for those options (e.g. if it's a radio button in the UI declaration, the option is of multiselect kind). This is plain wrong, the dependency should be wise versa. This will be addressed separately, since it's requires larger refactoring. For now the PreferencesFactory is obtained on demand. This will be addressed in a followup. Bug: T248527 Change-Id: I74917c5eaec184d188911a319895b941ed55ee87
2020-01-17 06:21:28 +00:00
*/
public function testGetDefaultOptionsHook() {
Tests: Mark more more closures as static Result of a new sniff I25a17fb22b6b669e817317a0f45051ae9c608208 Bug: T274036 Change-Id: I695873737167a75f0d94901fa40383a33984ca55
2021-02-07 13:10:36 +00:00
$this->setTemporaryHook( 'UserGetDefaultOptions', static function ( &$options ) {
Introduce UserOptionsManager and DefaultOptionsManager This converts user options management to a separate service for use in DI context. User options are accessed quite early on in installation process and full-on options management depends on the database. Prior we have protected from accessing the DB by setting a hacky $wgUser with 0 id, and relying on the implementation that it doesn't go into the database to get the default user options. Now we can't really do that since DBLoadBalancer is required to instantiate the options manager. Instead, we redefine the options manager with a DefaultOptionsManager, that only provides access to default options and doesn't require DB access. UserOptionsManager uses PreferencesFactory, however injecting it will produce a cyclic dependency. The problem is that we separate options to different kinds, which are inferred from the PreferencesFactory declaration for those options (e.g. if it's a radio button in the UI declaration, the option is of multiselect kind). This is plain wrong, the dependency should be wise versa. This will be addressed separately, since it's requires larger refactoring. For now the PreferencesFactory is obtained on demand. This will be addressed in a followup. Bug: T248527 Change-Id: I74917c5eaec184d188911a319895b941ed55ee87
2020-01-17 06:21:28 +00:00
$options['from_hook'] = 'value_from_hook';
} );
$this->assertSame( 'value_from_hook', $this->getLookup()->getDefaultOption( 'from_hook' ) );
}
/**
Rename DefaultOptionsManager to DefaultOptionsLookup This is not really a manager, since it only supports reading defaul options. Inroduced in 1.35 and not yet used outside of core, so no deprecations are needed. Change-Id: If67af54574d9c2e44ed85d1bdd098afd0a21e8f9
2020-05-11 19:19:13 +00:00
* @covers MediaWiki\User\DefaultOptionsLookup::getDefaultOptions
Introduce UserOptionsManager and DefaultOptionsManager This converts user options management to a separate service for use in DI context. User options are accessed quite early on in installation process and full-on options management depends on the database. Prior we have protected from accessing the DB by setting a hacky $wgUser with 0 id, and relying on the implementation that it doesn't go into the database to get the default user options. Now we can't really do that since DBLoadBalancer is required to instantiate the options manager. Instead, we redefine the options manager with a DefaultOptionsManager, that only provides access to default options and doesn't require DB access. UserOptionsManager uses PreferencesFactory, however injecting it will produce a cyclic dependency. The problem is that we separate options to different kinds, which are inferred from the PreferencesFactory declaration for those options (e.g. if it's a radio button in the UI declaration, the option is of multiselect kind). This is plain wrong, the dependency should be wise versa. This will be addressed separately, since it's requires larger refactoring. For now the PreferencesFactory is obtained on demand. This will be addressed in a followup. Bug: T248527 Change-Id: I74917c5eaec184d188911a319895b941ed55ee87
2020-01-17 06:21:28 +00:00
*/
public function testSearchNS() {
user: Set a default value for all searchNs* user preferences Without the default the preference is never deleted from the database, even it was disabled by the user. This can be tested by check "all" on Special:Search and save it for future searches. After checking "none" and selecting the main namespace and save it for future searches there still the other searchNS options on the database. Bug: T291748 Change-Id: Idb3a8774b82f5f27fbeda4537dfdacf59768e8c0
2021-09-29 09:03:32 +00:00
$lookup = $this->getLookup();
$this->assertSame( 1, $lookup->getDefaultOption( 'searchNs0' ) );
$this->assertSame( 0, $lookup->getDefaultOption( 'searchNs8' ) );
$this->assertSame( 0, $lookup->getDefaultOption( 'searchNs9' ) );
// Special namespace is not searchable and does not have a default
$this->assertNull( $lookup->getDefaultOption( 'searchNs-1' ) );
Introduce UserOptionsManager and DefaultOptionsManager This converts user options management to a separate service for use in DI context. User options are accessed quite early on in installation process and full-on options management depends on the database. Prior we have protected from accessing the DB by setting a hacky $wgUser with 0 id, and relying on the implementation that it doesn't go into the database to get the default user options. Now we can't really do that since DBLoadBalancer is required to instantiate the options manager. Instead, we redefine the options manager with a DefaultOptionsManager, that only provides access to default options and doesn't require DB access. UserOptionsManager uses PreferencesFactory, however injecting it will produce a cyclic dependency. The problem is that we separate options to different kinds, which are inferred from the PreferencesFactory declaration for those options (e.g. if it's a radio button in the UI declaration, the option is of multiselect kind). This is plain wrong, the dependency should be wise versa. This will be addressed separately, since it's requires larger refactoring. For now the PreferencesFactory is obtained on demand. This will be addressed in a followup. Bug: T248527 Change-Id: I74917c5eaec184d188911a319895b941ed55ee87
2020-01-17 06:21:28 +00:00
}
/**
Rename DefaultOptionsManager to DefaultOptionsLookup This is not really a manager, since it only supports reading defaul options. Inroduced in 1.35 and not yet used outside of core, so no deprecations are needed. Change-Id: If67af54574d9c2e44ed85d1bdd098afd0a21e8f9
2020-05-11 19:19:13 +00:00
* @covers MediaWiki\User\DefaultOptionsLookup::getDefaultOptions
Introduce UserOptionsManager and DefaultOptionsManager This converts user options management to a separate service for use in DI context. User options are accessed quite early on in installation process and full-on options management depends on the database. Prior we have protected from accessing the DB by setting a hacky $wgUser with 0 id, and relying on the implementation that it doesn't go into the database to get the default user options. Now we can't really do that since DBLoadBalancer is required to instantiate the options manager. Instead, we redefine the options manager with a DefaultOptionsManager, that only provides access to default options and doesn't require DB access. UserOptionsManager uses PreferencesFactory, however injecting it will produce a cyclic dependency. The problem is that we separate options to different kinds, which are inferred from the PreferencesFactory declaration for those options (e.g. if it's a radio button in the UI declaration, the option is of multiselect kind). This is plain wrong, the dependency should be wise versa. This will be addressed separately, since it's requires larger refactoring. For now the PreferencesFactory is obtained on demand. This will be addressed in a followup. Bug: T248527 Change-Id: I74917c5eaec184d188911a319895b941ed55ee87
2020-01-17 06:21:28 +00:00
*/
public function testLangVariantOptions() {
$managerZh = $this->getLookup( 'zh' );
$this->assertSame( 'zh', $managerZh->getDefaultOption( 'language' ) );
$this->assertSame( 'gan', $managerZh->getDefaultOption( 'variant-gan' ) );
$this->assertSame( 'zh', $managerZh->getDefaultOption( 'variant' ) );
}
}
Reference in a new issue Copy permalink