wiki.techinc.nl/tests/phpunit/includes/specialpage/ChangesListSpecialPageTest.php

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

1293 lines
30 KiB
PHP
Raw Normal View History

Back-end of new RecentChanges page, refactoring Generate old RC, Related changes (it was already displayed and working on 'Related changes' before this change), and Watchlist/etc. and data for new UI from back-end. This moves everything used for defining the old (unstructured) and new (structured) filters into unified objects, ChangesListFilter and ChangesListFilterGroup (and sub-classes). This includes the query logic (see below) and logic for adding CSS attribution classes. This is a breaking change (for subclasses of ChangesListSpecialpage) due to the signature (and name) change of buildMainQueryConds and doMainQuery. An alternative that I don't think is a breaking change would be to put the filter->DB logic in runMainQueryHook, but then it's doing more than just running a hook. This is because it used to only build $conds here, but it's clear from filterOnUserExperienceLevel filters need more than this. I added all the DB parameters from the hook, but this could be debated. I have an checked and fixed the WMF-deployed extensions affected by this. Other than that, there should be full back-compat (including legacy filters not using the new system). * add hidepatrolled/hideunpatrolled to new UI. * Move userExpLevel from RC to ChangesListSpecialPage. Although for now the structured UI only displays on RC anyway, when it displays on watchlist, it seems we'll want userExpLevel there. Change this to make 'all' exclude unregistered users. * Don't have front-end convert none-selected to 'all' on string_options. * Needs the hideanons/hideliu special redirect to be done before this is merged (T151873) Bug: T152754 Bug: T152797 Change-Id: Iec2d82f6a830403d1c948a280efa58992e0cdee7
2017-02-14 07:55:37 +00:00
<?php
namespace MediaWiki\Tests\SpecialPage;
use ChangesListBooleanFilterGroup;
use ChangesListStringOptionsFilterGroup;
use MediaWiki\Context\RequestContext;
use MediaWiki\MainConfigNames;
use MediaWiki\Request\FauxRequest;
use MediaWiki\SpecialPage\ChangesListSpecialPage;
Support multiple matchPatterns in temp user autocreate config Why: * There is a need to update the generation and match pattern on WMF wikis to a new format that includes the year and starts with `~`. As such, the 'matchPattern' key needs to be updated. * Removing the old 'matchPattern' from the wgAutoCreateTempUser config currently leaves existing temporary accounts as no longer recongnised as temporary accounts. * Instead, the 'matchPattern' needs to be able to take an array of string patterns so that old patterns can still be used for matching. What: * Update the MainConfigSchama to indicate that 'matchPattern' in the wgAutoCreateTempUser config can be an array of strings. * Add TempUserConfig::getMatchPatterns and deprecate TempUserConfig:: getMatchPattern. This is needed because ::getMatchPattern was typed to only ever return one Pattern, which is no longer the case with this config change. * Update the RealTempUserConfig to support multiple patterns defined in the 'matchPattern' key. The RealTempUserConfig::getMatchPattern method returns the pattern or first pattern if multiple are defined to allow time for existing usages of this deprecated method to be updated. * Update the RealTempUserConfig to rely on other methods instead of checking object property values where possible (e.g. use ::isEnabled instead of checking $this->enabled) to allow easier unit testing. * Update UserSelectQueryBuilder and ChangesListSpecialPage to use TempUserConfig ::getMatchPatterns instead of ::getMatchPattern. * Update mediawiki.util/util.js to be able to parse the 'matchPattern' value when it is an array of strings. * Update maintenance/userOptions.php to use ::getMatchPatterns instead of ::getMatchPattern. * Add and update unit and integration tests for the new code, as well as expanding coverage over existing code that was indirectly affected. Bug: T354619 Change-Id: I3763daefe4dc7c76370bd934fb20452591c9c762
2024-01-10 23:40:27 +00:00
use MediaWiki\Tests\User\TempUser\TempUserTestTrait;
use MediaWiki\Title\Title;
use MediaWiki\User\User;
use Wikimedia\Rdbms\Database;
use Wikimedia\Rdbms\IExpression;
use Wikimedia\TestingAccessWrapper;
use Wikimedia\Timestamp\ConvertibleTimestamp;
Back-end of new RecentChanges page, refactoring Generate old RC, Related changes (it was already displayed and working on 'Related changes' before this change), and Watchlist/etc. and data for new UI from back-end. This moves everything used for defining the old (unstructured) and new (structured) filters into unified objects, ChangesListFilter and ChangesListFilterGroup (and sub-classes). This includes the query logic (see below) and logic for adding CSS attribution classes. This is a breaking change (for subclasses of ChangesListSpecialpage) due to the signature (and name) change of buildMainQueryConds and doMainQuery. An alternative that I don't think is a breaking change would be to put the filter->DB logic in runMainQueryHook, but then it's doing more than just running a hook. This is because it used to only build $conds here, but it's clear from filterOnUserExperienceLevel filters need more than this. I added all the DB parameters from the hook, but this could be debated. I have an checked and fixed the WMF-deployed extensions affected by this. Other than that, there should be full back-compat (including legacy filters not using the new system). * add hidepatrolled/hideunpatrolled to new UI. * Move userExpLevel from RC to ChangesListSpecialPage. Although for now the structured UI only displays on RC anyway, when it displays on watchlist, it seems we'll want userExpLevel there. Change this to make 'all' exclude unregistered users. * Don't have front-end convert none-selected to 'all' on string_options. * Needs the hideanons/hideliu special redirect to be done before this is merged (T151873) Bug: T152754 Bug: T152797 Change-Id: Iec2d82f6a830403d1c948a280efa58992e0cdee7
2017-02-14 07:55:37 +00:00
/**
* Test class for ChangesListSpecialPage class
*
* Copyright © 2011-, Antoine Musso, Stephane Bisson, Matthew Flaschen
*
* @author Antoine Musso
* @author Stephane Bisson
* @author Matthew Flaschen
* @group Database
*
* @covers \MediaWiki\SpecialPage\ChangesListSpecialPage
Back-end of new RecentChanges page, refactoring Generate old RC, Related changes (it was already displayed and working on 'Related changes' before this change), and Watchlist/etc. and data for new UI from back-end. This moves everything used for defining the old (unstructured) and new (structured) filters into unified objects, ChangesListFilter and ChangesListFilterGroup (and sub-classes). This includes the query logic (see below) and logic for adding CSS attribution classes. This is a breaking change (for subclasses of ChangesListSpecialpage) due to the signature (and name) change of buildMainQueryConds and doMainQuery. An alternative that I don't think is a breaking change would be to put the filter->DB logic in runMainQueryHook, but then it's doing more than just running a hook. This is because it used to only build $conds here, but it's clear from filterOnUserExperienceLevel filters need more than this. I added all the DB parameters from the hook, but this could be debated. I have an checked and fixed the WMF-deployed extensions affected by this. Other than that, there should be full back-compat (including legacy filters not using the new system). * add hidepatrolled/hideunpatrolled to new UI. * Move userExpLevel from RC to ChangesListSpecialPage. Although for now the structured UI only displays on RC anyway, when it displays on watchlist, it seems we'll want userExpLevel there. Change this to make 'all' exclude unregistered users. * Don't have front-end convert none-selected to 'all' on string_options. * Needs the hideanons/hideliu special redirect to be done before this is merged (T151873) Bug: T152754 Bug: T152797 Change-Id: Iec2d82f6a830403d1c948a280efa58992e0cdee7
2017-02-14 07:55:37 +00:00
*/
class ChangesListSpecialPageTest extends AbstractChangesListSpecialPageTestCase {
Support multiple matchPatterns in temp user autocreate config Why: * There is a need to update the generation and match pattern on WMF wikis to a new format that includes the year and starts with `~`. As such, the 'matchPattern' key needs to be updated. * Removing the old 'matchPattern' from the wgAutoCreateTempUser config currently leaves existing temporary accounts as no longer recongnised as temporary accounts. * Instead, the 'matchPattern' needs to be able to take an array of string patterns so that old patterns can still be used for matching. What: * Update the MainConfigSchama to indicate that 'matchPattern' in the wgAutoCreateTempUser config can be an array of strings. * Add TempUserConfig::getMatchPatterns and deprecate TempUserConfig:: getMatchPattern. This is needed because ::getMatchPattern was typed to only ever return one Pattern, which is no longer the case with this config change. * Update the RealTempUserConfig to support multiple patterns defined in the 'matchPattern' key. The RealTempUserConfig::getMatchPattern method returns the pattern or first pattern if multiple are defined to allow time for existing usages of this deprecated method to be updated. * Update the RealTempUserConfig to rely on other methods instead of checking object property values where possible (e.g. use ::isEnabled instead of checking $this->enabled) to allow easier unit testing. * Update UserSelectQueryBuilder and ChangesListSpecialPage to use TempUserConfig ::getMatchPatterns instead of ::getMatchPattern. * Update mediawiki.util/util.js to be able to parse the 'matchPattern' value when it is an array of strings. * Update maintenance/userOptions.php to use ::getMatchPatterns instead of ::getMatchPattern. * Add and update unit and integration tests for the new code, as well as expanding coverage over existing code that was indirectly affected. Bug: T354619 Change-Id: I3763daefe4dc7c76370bd934fb20452591c9c762
2024-01-10 23:40:27 +00:00
use TempUserTestTrait {
enableAutoCreateTempUser as _enableAutoCreateTempUser;
disableAutoCreateTempUser as _disableAutoCreateTempUser;
}
protected function setUp(): void {
parent::setUp();
$this->clearHooks();
}
/**
* @return ChangesListSpecialPage
*/
protected function getPageAccessWrapper() {
$mock = $this->getMockBuilder( ChangesListSpecialPage::class )
->setConstructorArgs(
Back-end of new RecentChanges page, refactoring Generate old RC, Related changes (it was already displayed and working on 'Related changes' before this change), and Watchlist/etc. and data for new UI from back-end. This moves everything used for defining the old (unstructured) and new (structured) filters into unified objects, ChangesListFilter and ChangesListFilterGroup (and sub-classes). This includes the query logic (see below) and logic for adding CSS attribution classes. This is a breaking change (for subclasses of ChangesListSpecialpage) due to the signature (and name) change of buildMainQueryConds and doMainQuery. An alternative that I don't think is a breaking change would be to put the filter->DB logic in runMainQueryHook, but then it's doing more than just running a hook. This is because it used to only build $conds here, but it's clear from filterOnUserExperienceLevel filters need more than this. I added all the DB parameters from the hook, but this could be debated. I have an checked and fixed the WMF-deployed extensions affected by this. Other than that, there should be full back-compat (including legacy filters not using the new system). * add hidepatrolled/hideunpatrolled to new UI. * Move userExpLevel from RC to ChangesListSpecialPage. Although for now the structured UI only displays on RC anyway, when it displays on watchlist, it seems we'll want userExpLevel there. Change this to make 'all' exclude unregistered users. * Don't have front-end convert none-selected to 'all' on string_options. * Needs the hideanons/hideliu special redirect to be done before this is merged (T151873) Bug: T152754 Bug: T152797 Change-Id: Iec2d82f6a830403d1c948a280efa58992e0cdee7
2017-02-14 07:55:37 +00:00
[
'ChangesListSpecialPage',
'',
$this->getServiceContainer()->getUserIdentityUtils(),
$this->getServiceContainer()->getTempUserConfig()
Back-end of new RecentChanges page, refactoring Generate old RC, Related changes (it was already displayed and working on 'Related changes' before this change), and Watchlist/etc. and data for new UI from back-end. This moves everything used for defining the old (unstructured) and new (structured) filters into unified objects, ChangesListFilter and ChangesListFilterGroup (and sub-classes). This includes the query logic (see below) and logic for adding CSS attribution classes. This is a breaking change (for subclasses of ChangesListSpecialpage) due to the signature (and name) change of buildMainQueryConds and doMainQuery. An alternative that I don't think is a breaking change would be to put the filter->DB logic in runMainQueryHook, but then it's doing more than just running a hook. This is because it used to only build $conds here, but it's clear from filterOnUserExperienceLevel filters need more than this. I added all the DB parameters from the hook, but this could be debated. I have an checked and fixed the WMF-deployed extensions affected by this. Other than that, there should be full back-compat (including legacy filters not using the new system). * add hidepatrolled/hideunpatrolled to new UI. * Move userExpLevel from RC to ChangesListSpecialPage. Although for now the structured UI only displays on RC anyway, when it displays on watchlist, it seems we'll want userExpLevel there. Change this to make 'all' exclude unregistered users. * Don't have front-end convert none-selected to 'all' on string_options. * Needs the hideanons/hideliu special redirect to be done before this is merged (T151873) Bug: T152754 Bug: T152797 Change-Id: Iec2d82f6a830403d1c948a280efa58992e0cdee7
2017-02-14 07:55:37 +00:00
]
)
->onlyMethods( [ 'getPageTitle' ] )
->getMockForAbstractClass();
$mock->method( 'getPageTitle' )->willReturn(
Title::makeTitle( NS_SPECIAL, 'ChangesListSpecialPage' )
Back-end of new RecentChanges page, refactoring Generate old RC, Related changes (it was already displayed and working on 'Related changes' before this change), and Watchlist/etc. and data for new UI from back-end. This moves everything used for defining the old (unstructured) and new (structured) filters into unified objects, ChangesListFilter and ChangesListFilterGroup (and sub-classes). This includes the query logic (see below) and logic for adding CSS attribution classes. This is a breaking change (for subclasses of ChangesListSpecialpage) due to the signature (and name) change of buildMainQueryConds and doMainQuery. An alternative that I don't think is a breaking change would be to put the filter->DB logic in runMainQueryHook, but then it's doing more than just running a hook. This is because it used to only build $conds here, but it's clear from filterOnUserExperienceLevel filters need more than this. I added all the DB parameters from the hook, but this could be debated. I have an checked and fixed the WMF-deployed extensions affected by this. Other than that, there should be full back-compat (including legacy filters not using the new system). * add hidepatrolled/hideunpatrolled to new UI. * Move userExpLevel from RC to ChangesListSpecialPage. Although for now the structured UI only displays on RC anyway, when it displays on watchlist, it seems we'll want userExpLevel there. Change this to make 'all' exclude unregistered users. * Don't have front-end convert none-selected to 'all' on string_options. * Needs the hideanons/hideliu special redirect to be done before this is merged (T151873) Bug: T152754 Bug: T152797 Change-Id: Iec2d82f6a830403d1c948a280efa58992e0cdee7
2017-02-14 07:55:37 +00:00
);
$mock = TestingAccessWrapper::newFromObject(
$mock
);
return $mock;
Back-end of new RecentChanges page, refactoring Generate old RC, Related changes (it was already displayed and working on 'Related changes' before this change), and Watchlist/etc. and data for new UI from back-end. This moves everything used for defining the old (unstructured) and new (structured) filters into unified objects, ChangesListFilter and ChangesListFilterGroup (and sub-classes). This includes the query logic (see below) and logic for adding CSS attribution classes. This is a breaking change (for subclasses of ChangesListSpecialpage) due to the signature (and name) change of buildMainQueryConds and doMainQuery. An alternative that I don't think is a breaking change would be to put the filter->DB logic in runMainQueryHook, but then it's doing more than just running a hook. This is because it used to only build $conds here, but it's clear from filterOnUserExperienceLevel filters need more than this. I added all the DB parameters from the hook, but this could be debated. I have an checked and fixed the WMF-deployed extensions affected by this. Other than that, there should be full back-compat (including legacy filters not using the new system). * add hidepatrolled/hideunpatrolled to new UI. * Move userExpLevel from RC to ChangesListSpecialPage. Although for now the structured UI only displays on RC anyway, when it displays on watchlist, it seems we'll want userExpLevel there. Change this to make 'all' exclude unregistered users. * Don't have front-end convert none-selected to 'all' on string_options. * Needs the hideanons/hideliu special redirect to be done before this is merged (T151873) Bug: T152754 Bug: T152797 Change-Id: Iec2d82f6a830403d1c948a280efa58992e0cdee7
2017-02-14 07:55:37 +00:00
}
private function buildQuery(
array $requestOptions,
?User $user = null
): array {
Back-end of new RecentChanges page, refactoring Generate old RC, Related changes (it was already displayed and working on 'Related changes' before this change), and Watchlist/etc. and data for new UI from back-end. This moves everything used for defining the old (unstructured) and new (structured) filters into unified objects, ChangesListFilter and ChangesListFilterGroup (and sub-classes). This includes the query logic (see below) and logic for adding CSS attribution classes. This is a breaking change (for subclasses of ChangesListSpecialpage) due to the signature (and name) change of buildMainQueryConds and doMainQuery. An alternative that I don't think is a breaking change would be to put the filter->DB logic in runMainQueryHook, but then it's doing more than just running a hook. This is because it used to only build $conds here, but it's clear from filterOnUserExperienceLevel filters need more than this. I added all the DB parameters from the hook, but this could be debated. I have an checked and fixed the WMF-deployed extensions affected by this. Other than that, there should be full back-compat (including legacy filters not using the new system). * add hidepatrolled/hideunpatrolled to new UI. * Move userExpLevel from RC to ChangesListSpecialPage. Although for now the structured UI only displays on RC anyway, when it displays on watchlist, it seems we'll want userExpLevel there. Change this to make 'all' exclude unregistered users. * Don't have front-end convert none-selected to 'all' on string_options. * Needs the hideanons/hideliu special redirect to be done before this is merged (T151873) Bug: T152754 Bug: T152797 Change-Id: Iec2d82f6a830403d1c948a280efa58992e0cdee7
2017-02-14 07:55:37 +00:00
$context = new RequestContext;
$context->setRequest( new FauxRequest( $requestOptions ) );
if ( $user ) {
$context->setUser( $user );
}
$this->changesListSpecialPage->setContext( $context );
$this->changesListSpecialPage->filterGroups = [];
Back-end of new RecentChanges page, refactoring Generate old RC, Related changes (it was already displayed and working on 'Related changes' before this change), and Watchlist/etc. and data for new UI from back-end. This moves everything used for defining the old (unstructured) and new (structured) filters into unified objects, ChangesListFilter and ChangesListFilterGroup (and sub-classes). This includes the query logic (see below) and logic for adding CSS attribution classes. This is a breaking change (for subclasses of ChangesListSpecialpage) due to the signature (and name) change of buildMainQueryConds and doMainQuery. An alternative that I don't think is a breaking change would be to put the filter->DB logic in runMainQueryHook, but then it's doing more than just running a hook. This is because it used to only build $conds here, but it's clear from filterOnUserExperienceLevel filters need more than this. I added all the DB parameters from the hook, but this could be debated. I have an checked and fixed the WMF-deployed extensions affected by this. Other than that, there should be full back-compat (including legacy filters not using the new system). * add hidepatrolled/hideunpatrolled to new UI. * Move userExpLevel from RC to ChangesListSpecialPage. Although for now the structured UI only displays on RC anyway, when it displays on watchlist, it seems we'll want userExpLevel there. Change this to make 'all' exclude unregistered users. * Don't have front-end convert none-selected to 'all' on string_options. * Needs the hideanons/hideliu special redirect to be done before this is merged (T151873) Bug: T152754 Bug: T152797 Change-Id: Iec2d82f6a830403d1c948a280efa58992e0cdee7
2017-02-14 07:55:37 +00:00
$formOptions = $this->changesListSpecialPage->setup( null );
# Filter out rc_timestamp conditions which depends on the test runtime
Back-end of new RecentChanges page, refactoring Generate old RC, Related changes (it was already displayed and working on 'Related changes' before this change), and Watchlist/etc. and data for new UI from back-end. This moves everything used for defining the old (unstructured) and new (structured) filters into unified objects, ChangesListFilter and ChangesListFilterGroup (and sub-classes). This includes the query logic (see below) and logic for adding CSS attribution classes. This is a breaking change (for subclasses of ChangesListSpecialpage) due to the signature (and name) change of buildMainQueryConds and doMainQuery. An alternative that I don't think is a breaking change would be to put the filter->DB logic in runMainQueryHook, but then it's doing more than just running a hook. This is because it used to only build $conds here, but it's clear from filterOnUserExperienceLevel filters need more than this. I added all the DB parameters from the hook, but this could be debated. I have an checked and fixed the WMF-deployed extensions affected by this. Other than that, there should be full back-compat (including legacy filters not using the new system). * add hidepatrolled/hideunpatrolled to new UI. * Move userExpLevel from RC to ChangesListSpecialPage. Although for now the structured UI only displays on RC anyway, when it displays on watchlist, it seems we'll want userExpLevel there. Change this to make 'all' exclude unregistered users. * Don't have front-end convert none-selected to 'all' on string_options. * Needs the hideanons/hideliu special redirect to be done before this is merged (T151873) Bug: T152754 Bug: T152797 Change-Id: Iec2d82f6a830403d1c948a280efa58992e0cdee7
2017-02-14 07:55:37 +00:00
# This condition is not needed as of march 2, 2011 -- hashar
# @todo FIXME: Find a way to generate the correct rc_timestamp
$tables = [];
$fields = [];
$queryConditions = [];
$query_options = [];
$join_conds = [];
call_user_func_array(
[ $this->changesListSpecialPage, 'buildQuery' ],
[
&$tables,
&$fields,
&$queryConditions,
&$query_options,
&$join_conds,
$formOptions
]
);
$queryConditions = array_filter(
$queryConditions,
[ __CLASS__, 'filterOutRcTimestampCondition' ]
Back-end of new RecentChanges page, refactoring Generate old RC, Related changes (it was already displayed and working on 'Related changes' before this change), and Watchlist/etc. and data for new UI from back-end. This moves everything used for defining the old (unstructured) and new (structured) filters into unified objects, ChangesListFilter and ChangesListFilterGroup (and sub-classes). This includes the query logic (see below) and logic for adding CSS attribution classes. This is a breaking change (for subclasses of ChangesListSpecialpage) due to the signature (and name) change of buildMainQueryConds and doMainQuery. An alternative that I don't think is a breaking change would be to put the filter->DB logic in runMainQueryHook, but then it's doing more than just running a hook. This is because it used to only build $conds here, but it's clear from filterOnUserExperienceLevel filters need more than this. I added all the DB parameters from the hook, but this could be debated. I have an checked and fixed the WMF-deployed extensions affected by this. Other than that, there should be full back-compat (including legacy filters not using the new system). * add hidepatrolled/hideunpatrolled to new UI. * Move userExpLevel from RC to ChangesListSpecialPage. Although for now the structured UI only displays on RC anyway, when it displays on watchlist, it seems we'll want userExpLevel there. Change this to make 'all' exclude unregistered users. * Don't have front-end convert none-selected to 'all' on string_options. * Needs the hideanons/hideliu special redirect to be done before this is merged (T151873) Bug: T152754 Bug: T152797 Change-Id: Iec2d82f6a830403d1c948a280efa58992e0cdee7
2017-02-14 07:55:37 +00:00
);
return $queryConditions;
}
/**
* helper to test SpecialRecentchanges::buildQuery()
* @param array $expected
* @param array $requestOptions
* @param string $message
* @param User|null $user
*/
private function assertConditions(
array $expected,
array $requestOptions,
string $message,
?User $user = null
) {
$queryConditions = $this->buildQuery( $requestOptions, $user );
Back-end of new RecentChanges page, refactoring Generate old RC, Related changes (it was already displayed and working on 'Related changes' before this change), and Watchlist/etc. and data for new UI from back-end. This moves everything used for defining the old (unstructured) and new (structured) filters into unified objects, ChangesListFilter and ChangesListFilterGroup (and sub-classes). This includes the query logic (see below) and logic for adding CSS attribution classes. This is a breaking change (for subclasses of ChangesListSpecialpage) due to the signature (and name) change of buildMainQueryConds and doMainQuery. An alternative that I don't think is a breaking change would be to put the filter->DB logic in runMainQueryHook, but then it's doing more than just running a hook. This is because it used to only build $conds here, but it's clear from filterOnUserExperienceLevel filters need more than this. I added all the DB parameters from the hook, but this could be debated. I have an checked and fixed the WMF-deployed extensions affected by this. Other than that, there should be full back-compat (including legacy filters not using the new system). * add hidepatrolled/hideunpatrolled to new UI. * Move userExpLevel from RC to ChangesListSpecialPage. Although for now the structured UI only displays on RC anyway, when it displays on watchlist, it seems we'll want userExpLevel there. Change this to make 'all' exclude unregistered users. * Don't have front-end convert none-selected to 'all' on string_options. * Needs the hideanons/hideliu special redirect to be done before this is merged (T151873) Bug: T152754 Bug: T152797 Change-Id: Iec2d82f6a830403d1c948a280efa58992e0cdee7
2017-02-14 07:55:37 +00:00
$this->assertEquals(
$this->normalizeCondition( $expected ),
$this->normalizeCondition( $queryConditions ),
Back-end of new RecentChanges page, refactoring Generate old RC, Related changes (it was already displayed and working on 'Related changes' before this change), and Watchlist/etc. and data for new UI from back-end. This moves everything used for defining the old (unstructured) and new (structured) filters into unified objects, ChangesListFilter and ChangesListFilterGroup (and sub-classes). This includes the query logic (see below) and logic for adding CSS attribution classes. This is a breaking change (for subclasses of ChangesListSpecialpage) due to the signature (and name) change of buildMainQueryConds and doMainQuery. An alternative that I don't think is a breaking change would be to put the filter->DB logic in runMainQueryHook, but then it's doing more than just running a hook. This is because it used to only build $conds here, but it's clear from filterOnUserExperienceLevel filters need more than this. I added all the DB parameters from the hook, but this could be debated. I have an checked and fixed the WMF-deployed extensions affected by this. Other than that, there should be full back-compat (including legacy filters not using the new system). * add hidepatrolled/hideunpatrolled to new UI. * Move userExpLevel from RC to ChangesListSpecialPage. Although for now the structured UI only displays on RC anyway, when it displays on watchlist, it seems we'll want userExpLevel there. Change this to make 'all' exclude unregistered users. * Don't have front-end convert none-selected to 'all' on string_options. * Needs the hideanons/hideliu special redirect to be done before this is merged (T151873) Bug: T152754 Bug: T152797 Change-Id: Iec2d82f6a830403d1c948a280efa58992e0cdee7
2017-02-14 07:55:37 +00:00
$message
);
}
private function normalizeCondition( array $conds ): array {
$dbr = $this->getDb();
Back-end of new RecentChanges page, refactoring Generate old RC, Related changes (it was already displayed and working on 'Related changes' before this change), and Watchlist/etc. and data for new UI from back-end. This moves everything used for defining the old (unstructured) and new (structured) filters into unified objects, ChangesListFilter and ChangesListFilterGroup (and sub-classes). This includes the query logic (see below) and logic for adding CSS attribution classes. This is a breaking change (for subclasses of ChangesListSpecialpage) due to the signature (and name) change of buildMainQueryConds and doMainQuery. An alternative that I don't think is a breaking change would be to put the filter->DB logic in runMainQueryHook, but then it's doing more than just running a hook. This is because it used to only build $conds here, but it's clear from filterOnUserExperienceLevel filters need more than this. I added all the DB parameters from the hook, but this could be debated. I have an checked and fixed the WMF-deployed extensions affected by this. Other than that, there should be full back-compat (including legacy filters not using the new system). * add hidepatrolled/hideunpatrolled to new UI. * Move userExpLevel from RC to ChangesListSpecialPage. Although for now the structured UI only displays on RC anyway, when it displays on watchlist, it seems we'll want userExpLevel there. Change this to make 'all' exclude unregistered users. * Don't have front-end convert none-selected to 'all' on string_options. * Needs the hideanons/hideliu special redirect to be done before this is merged (T151873) Bug: T152754 Bug: T152797 Change-Id: Iec2d82f6a830403d1c948a280efa58992e0cdee7
2017-02-14 07:55:37 +00:00
$normalized = array_map(
static function ( $k, $v ) use ( $dbr ) {
if ( is_array( $v ) ) {
sort( $v );
}
// (Ab)use makeList() to format only this entry
return $dbr->makeList( [ $k => $v ], Database::LIST_AND );
Back-end of new RecentChanges page, refactoring Generate old RC, Related changes (it was already displayed and working on 'Related changes' before this change), and Watchlist/etc. and data for new UI from back-end. This moves everything used for defining the old (unstructured) and new (structured) filters into unified objects, ChangesListFilter and ChangesListFilterGroup (and sub-classes). This includes the query logic (see below) and logic for adding CSS attribution classes. This is a breaking change (for subclasses of ChangesListSpecialpage) due to the signature (and name) change of buildMainQueryConds and doMainQuery. An alternative that I don't think is a breaking change would be to put the filter->DB logic in runMainQueryHook, but then it's doing more than just running a hook. This is because it used to only build $conds here, but it's clear from filterOnUserExperienceLevel filters need more than this. I added all the DB parameters from the hook, but this could be debated. I have an checked and fixed the WMF-deployed extensions affected by this. Other than that, there should be full back-compat (including legacy filters not using the new system). * add hidepatrolled/hideunpatrolled to new UI. * Move userExpLevel from RC to ChangesListSpecialPage. Although for now the structured UI only displays on RC anyway, when it displays on watchlist, it seems we'll want userExpLevel there. Change this to make 'all' exclude unregistered users. * Don't have front-end convert none-selected to 'all' on string_options. * Needs the hideanons/hideliu special redirect to be done before this is merged (T151873) Bug: T152754 Bug: T152797 Change-Id: Iec2d82f6a830403d1c948a280efa58992e0cdee7
2017-02-14 07:55:37 +00:00
},
array_keys( $conds ),
$conds
);
sort( $normalized );
return $normalized;
}
/**
* @param array|string|IExpression $var
* @return bool false if condition begins with 'rc_timestamp '
*/
private static function filterOutRcTimestampCondition( $var ): bool {
if ( $var instanceof IExpression ) {
$var = $var->toGeneralizedSql();
}
return is_array( $var ) || !str_contains( (string)$var, 'rc_timestamp ' );
Back-end of new RecentChanges page, refactoring Generate old RC, Related changes (it was already displayed and working on 'Related changes' before this change), and Watchlist/etc. and data for new UI from back-end. This moves everything used for defining the old (unstructured) and new (structured) filters into unified objects, ChangesListFilter and ChangesListFilterGroup (and sub-classes). This includes the query logic (see below) and logic for adding CSS attribution classes. This is a breaking change (for subclasses of ChangesListSpecialpage) due to the signature (and name) change of buildMainQueryConds and doMainQuery. An alternative that I don't think is a breaking change would be to put the filter->DB logic in runMainQueryHook, but then it's doing more than just running a hook. This is because it used to only build $conds here, but it's clear from filterOnUserExperienceLevel filters need more than this. I added all the DB parameters from the hook, but this could be debated. I have an checked and fixed the WMF-deployed extensions affected by this. Other than that, there should be full back-compat (including legacy filters not using the new system). * add hidepatrolled/hideunpatrolled to new UI. * Move userExpLevel from RC to ChangesListSpecialPage. Although for now the structured UI only displays on RC anyway, when it displays on watchlist, it seems we'll want userExpLevel there. Change this to make 'all' exclude unregistered users. * Don't have front-end convert none-selected to 'all' on string_options. * Needs the hideanons/hideliu special redirect to be done before this is merged (T151873) Bug: T152754 Bug: T152797 Change-Id: Iec2d82f6a830403d1c948a280efa58992e0cdee7
2017-02-14 07:55:37 +00:00
}
public function testRcNsFilter() {
$this->assertConditions(
[ # expected
'rc_namespace = 0',
Back-end of new RecentChanges page, refactoring Generate old RC, Related changes (it was already displayed and working on 'Related changes' before this change), and Watchlist/etc. and data for new UI from back-end. This moves everything used for defining the old (unstructured) and new (structured) filters into unified objects, ChangesListFilter and ChangesListFilterGroup (and sub-classes). This includes the query logic (see below) and logic for adding CSS attribution classes. This is a breaking change (for subclasses of ChangesListSpecialpage) due to the signature (and name) change of buildMainQueryConds and doMainQuery. An alternative that I don't think is a breaking change would be to put the filter->DB logic in runMainQueryHook, but then it's doing more than just running a hook. This is because it used to only build $conds here, but it's clear from filterOnUserExperienceLevel filters need more than this. I added all the DB parameters from the hook, but this could be debated. I have an checked and fixed the WMF-deployed extensions affected by this. Other than that, there should be full back-compat (including legacy filters not using the new system). * add hidepatrolled/hideunpatrolled to new UI. * Move userExpLevel from RC to ChangesListSpecialPage. Although for now the structured UI only displays on RC anyway, when it displays on watchlist, it seems we'll want userExpLevel there. Change this to make 'all' exclude unregistered users. * Don't have front-end convert none-selected to 'all' on string_options. * Needs the hideanons/hideliu special redirect to be done before this is merged (T151873) Bug: T152754 Bug: T152797 Change-Id: Iec2d82f6a830403d1c948a280efa58992e0cdee7
2017-02-14 07:55:37 +00:00
],
[
'namespace' => NS_MAIN,
],
"rc conditions with one namespace"
Back-end of new RecentChanges page, refactoring Generate old RC, Related changes (it was already displayed and working on 'Related changes' before this change), and Watchlist/etc. and data for new UI from back-end. This moves everything used for defining the old (unstructured) and new (structured) filters into unified objects, ChangesListFilter and ChangesListFilterGroup (and sub-classes). This includes the query logic (see below) and logic for adding CSS attribution classes. This is a breaking change (for subclasses of ChangesListSpecialpage) due to the signature (and name) change of buildMainQueryConds and doMainQuery. An alternative that I don't think is a breaking change would be to put the filter->DB logic in runMainQueryHook, but then it's doing more than just running a hook. This is because it used to only build $conds here, but it's clear from filterOnUserExperienceLevel filters need more than this. I added all the DB parameters from the hook, but this could be debated. I have an checked and fixed the WMF-deployed extensions affected by this. Other than that, there should be full back-compat (including legacy filters not using the new system). * add hidepatrolled/hideunpatrolled to new UI. * Move userExpLevel from RC to ChangesListSpecialPage. Although for now the structured UI only displays on RC anyway, when it displays on watchlist, it seems we'll want userExpLevel there. Change this to make 'all' exclude unregistered users. * Don't have front-end convert none-selected to 'all' on string_options. * Needs the hideanons/hideliu special redirect to be done before this is merged (T151873) Bug: T152754 Bug: T152797 Change-Id: Iec2d82f6a830403d1c948a280efa58992e0cdee7
2017-02-14 07:55:37 +00:00
);
}
public function testRcNsFilterInversion() {
$this->assertConditions(
[ # expected
'rc_namespace != 0',
Back-end of new RecentChanges page, refactoring Generate old RC, Related changes (it was already displayed and working on 'Related changes' before this change), and Watchlist/etc. and data for new UI from back-end. This moves everything used for defining the old (unstructured) and new (structured) filters into unified objects, ChangesListFilter and ChangesListFilterGroup (and sub-classes). This includes the query logic (see below) and logic for adding CSS attribution classes. This is a breaking change (for subclasses of ChangesListSpecialpage) due to the signature (and name) change of buildMainQueryConds and doMainQuery. An alternative that I don't think is a breaking change would be to put the filter->DB logic in runMainQueryHook, but then it's doing more than just running a hook. This is because it used to only build $conds here, but it's clear from filterOnUserExperienceLevel filters need more than this. I added all the DB parameters from the hook, but this could be debated. I have an checked and fixed the WMF-deployed extensions affected by this. Other than that, there should be full back-compat (including legacy filters not using the new system). * add hidepatrolled/hideunpatrolled to new UI. * Move userExpLevel from RC to ChangesListSpecialPage. Although for now the structured UI only displays on RC anyway, when it displays on watchlist, it seems we'll want userExpLevel there. Change this to make 'all' exclude unregistered users. * Don't have front-end convert none-selected to 'all' on string_options. * Needs the hideanons/hideliu special redirect to be done before this is merged (T151873) Bug: T152754 Bug: T152797 Change-Id: Iec2d82f6a830403d1c948a280efa58992e0cdee7
2017-02-14 07:55:37 +00:00
],
[
'namespace' => NS_MAIN,
'invert' => 1,
],
"rc conditions with namespace inverted"
);
}
public function testRcNsFilterMultiple() {
Back-end of new RecentChanges page, refactoring Generate old RC, Related changes (it was already displayed and working on 'Related changes' before this change), and Watchlist/etc. and data for new UI from back-end. This moves everything used for defining the old (unstructured) and new (structured) filters into unified objects, ChangesListFilter and ChangesListFilterGroup (and sub-classes). This includes the query logic (see below) and logic for adding CSS attribution classes. This is a breaking change (for subclasses of ChangesListSpecialpage) due to the signature (and name) change of buildMainQueryConds and doMainQuery. An alternative that I don't think is a breaking change would be to put the filter->DB logic in runMainQueryHook, but then it's doing more than just running a hook. This is because it used to only build $conds here, but it's clear from filterOnUserExperienceLevel filters need more than this. I added all the DB parameters from the hook, but this could be debated. I have an checked and fixed the WMF-deployed extensions affected by this. Other than that, there should be full back-compat (including legacy filters not using the new system). * add hidepatrolled/hideunpatrolled to new UI. * Move userExpLevel from RC to ChangesListSpecialPage. Although for now the structured UI only displays on RC anyway, when it displays on watchlist, it seems we'll want userExpLevel there. Change this to make 'all' exclude unregistered users. * Don't have front-end convert none-selected to 'all' on string_options. * Needs the hideanons/hideliu special redirect to be done before this is merged (T151873) Bug: T152754 Bug: T152797 Change-Id: Iec2d82f6a830403d1c948a280efa58992e0cdee7
2017-02-14 07:55:37 +00:00
$this->assertConditions(
[ # expected
'rc_namespace IN (1,2,3)',
Back-end of new RecentChanges page, refactoring Generate old RC, Related changes (it was already displayed and working on 'Related changes' before this change), and Watchlist/etc. and data for new UI from back-end. This moves everything used for defining the old (unstructured) and new (structured) filters into unified objects, ChangesListFilter and ChangesListFilterGroup (and sub-classes). This includes the query logic (see below) and logic for adding CSS attribution classes. This is a breaking change (for subclasses of ChangesListSpecialpage) due to the signature (and name) change of buildMainQueryConds and doMainQuery. An alternative that I don't think is a breaking change would be to put the filter->DB logic in runMainQueryHook, but then it's doing more than just running a hook. This is because it used to only build $conds here, but it's clear from filterOnUserExperienceLevel filters need more than this. I added all the DB parameters from the hook, but this could be debated. I have an checked and fixed the WMF-deployed extensions affected by this. Other than that, there should be full back-compat (including legacy filters not using the new system). * add hidepatrolled/hideunpatrolled to new UI. * Move userExpLevel from RC to ChangesListSpecialPage. Although for now the structured UI only displays on RC anyway, when it displays on watchlist, it seems we'll want userExpLevel there. Change this to make 'all' exclude unregistered users. * Don't have front-end convert none-selected to 'all' on string_options. * Needs the hideanons/hideliu special redirect to be done before this is merged (T151873) Bug: T152754 Bug: T152797 Change-Id: Iec2d82f6a830403d1c948a280efa58992e0cdee7
2017-02-14 07:55:37 +00:00
],
[
'namespace' => '1;2;3',
],
"rc conditions with multiple namespaces"
);
}
public function testRcNsFilterMultipleAssociated() {
$this->assertConditions(
[ # expected
'rc_namespace IN (0,1,4,5,6,7)',
],
[
'namespace' => '1;4;7',
Back-end of new RecentChanges page, refactoring Generate old RC, Related changes (it was already displayed and working on 'Related changes' before this change), and Watchlist/etc. and data for new UI from back-end. This moves everything used for defining the old (unstructured) and new (structured) filters into unified objects, ChangesListFilter and ChangesListFilterGroup (and sub-classes). This includes the query logic (see below) and logic for adding CSS attribution classes. This is a breaking change (for subclasses of ChangesListSpecialpage) due to the signature (and name) change of buildMainQueryConds and doMainQuery. An alternative that I don't think is a breaking change would be to put the filter->DB logic in runMainQueryHook, but then it's doing more than just running a hook. This is because it used to only build $conds here, but it's clear from filterOnUserExperienceLevel filters need more than this. I added all the DB parameters from the hook, but this could be debated. I have an checked and fixed the WMF-deployed extensions affected by this. Other than that, there should be full back-compat (including legacy filters not using the new system). * add hidepatrolled/hideunpatrolled to new UI. * Move userExpLevel from RC to ChangesListSpecialPage. Although for now the structured UI only displays on RC anyway, when it displays on watchlist, it seems we'll want userExpLevel there. Change this to make 'all' exclude unregistered users. * Don't have front-end convert none-selected to 'all' on string_options. * Needs the hideanons/hideliu special redirect to be done before this is merged (T151873) Bug: T152754 Bug: T152797 Change-Id: Iec2d82f6a830403d1c948a280efa58992e0cdee7
2017-02-14 07:55:37 +00:00
'associated' => 1,
],
"rc conditions with multiple namespaces and associated"
Back-end of new RecentChanges page, refactoring Generate old RC, Related changes (it was already displayed and working on 'Related changes' before this change), and Watchlist/etc. and data for new UI from back-end. This moves everything used for defining the old (unstructured) and new (structured) filters into unified objects, ChangesListFilter and ChangesListFilterGroup (and sub-classes). This includes the query logic (see below) and logic for adding CSS attribution classes. This is a breaking change (for subclasses of ChangesListSpecialpage) due to the signature (and name) change of buildMainQueryConds and doMainQuery. An alternative that I don't think is a breaking change would be to put the filter->DB logic in runMainQueryHook, but then it's doing more than just running a hook. This is because it used to only build $conds here, but it's clear from filterOnUserExperienceLevel filters need more than this. I added all the DB parameters from the hook, but this could be debated. I have an checked and fixed the WMF-deployed extensions affected by this. Other than that, there should be full back-compat (including legacy filters not using the new system). * add hidepatrolled/hideunpatrolled to new UI. * Move userExpLevel from RC to ChangesListSpecialPage. Although for now the structured UI only displays on RC anyway, when it displays on watchlist, it seems we'll want userExpLevel there. Change this to make 'all' exclude unregistered users. * Don't have front-end convert none-selected to 'all' on string_options. * Needs the hideanons/hideliu special redirect to be done before this is merged (T151873) Bug: T152754 Bug: T152797 Change-Id: Iec2d82f6a830403d1c948a280efa58992e0cdee7
2017-02-14 07:55:37 +00:00
);
}
public function testRcNsFilterAssociatedSpecial() {
$this->assertConditions(
[ # expected
'rc_namespace IN (-1,0,1)',
],
[
'namespace' => '1;-1',
'associated' => 1,
],
"rc conditions with associated and special namespace"
);
}
public function testRcNsFilterMultipleAssociatedInvert() {
Back-end of new RecentChanges page, refactoring Generate old RC, Related changes (it was already displayed and working on 'Related changes' before this change), and Watchlist/etc. and data for new UI from back-end. This moves everything used for defining the old (unstructured) and new (structured) filters into unified objects, ChangesListFilter and ChangesListFilterGroup (and sub-classes). This includes the query logic (see below) and logic for adding CSS attribution classes. This is a breaking change (for subclasses of ChangesListSpecialpage) due to the signature (and name) change of buildMainQueryConds and doMainQuery. An alternative that I don't think is a breaking change would be to put the filter->DB logic in runMainQueryHook, but then it's doing more than just running a hook. This is because it used to only build $conds here, but it's clear from filterOnUserExperienceLevel filters need more than this. I added all the DB parameters from the hook, but this could be debated. I have an checked and fixed the WMF-deployed extensions affected by this. Other than that, there should be full back-compat (including legacy filters not using the new system). * add hidepatrolled/hideunpatrolled to new UI. * Move userExpLevel from RC to ChangesListSpecialPage. Although for now the structured UI only displays on RC anyway, when it displays on watchlist, it seems we'll want userExpLevel there. Change this to make 'all' exclude unregistered users. * Don't have front-end convert none-selected to 'all' on string_options. * Needs the hideanons/hideliu special redirect to be done before this is merged (T151873) Bug: T152754 Bug: T152797 Change-Id: Iec2d82f6a830403d1c948a280efa58992e0cdee7
2017-02-14 07:55:37 +00:00
$this->assertConditions(
[ # expected
'rc_namespace NOT IN (2,3,8,9)',
Back-end of new RecentChanges page, refactoring Generate old RC, Related changes (it was already displayed and working on 'Related changes' before this change), and Watchlist/etc. and data for new UI from back-end. This moves everything used for defining the old (unstructured) and new (structured) filters into unified objects, ChangesListFilter and ChangesListFilterGroup (and sub-classes). This includes the query logic (see below) and logic for adding CSS attribution classes. This is a breaking change (for subclasses of ChangesListSpecialpage) due to the signature (and name) change of buildMainQueryConds and doMainQuery. An alternative that I don't think is a breaking change would be to put the filter->DB logic in runMainQueryHook, but then it's doing more than just running a hook. This is because it used to only build $conds here, but it's clear from filterOnUserExperienceLevel filters need more than this. I added all the DB parameters from the hook, but this could be debated. I have an checked and fixed the WMF-deployed extensions affected by this. Other than that, there should be full back-compat (including legacy filters not using the new system). * add hidepatrolled/hideunpatrolled to new UI. * Move userExpLevel from RC to ChangesListSpecialPage. Although for now the structured UI only displays on RC anyway, when it displays on watchlist, it seems we'll want userExpLevel there. Change this to make 'all' exclude unregistered users. * Don't have front-end convert none-selected to 'all' on string_options. * Needs the hideanons/hideliu special redirect to be done before this is merged (T151873) Bug: T152754 Bug: T152797 Change-Id: Iec2d82f6a830403d1c948a280efa58992e0cdee7
2017-02-14 07:55:37 +00:00
],
[
'namespace' => '2;3;9',
Back-end of new RecentChanges page, refactoring Generate old RC, Related changes (it was already displayed and working on 'Related changes' before this change), and Watchlist/etc. and data for new UI from back-end. This moves everything used for defining the old (unstructured) and new (structured) filters into unified objects, ChangesListFilter and ChangesListFilterGroup (and sub-classes). This includes the query logic (see below) and logic for adding CSS attribution classes. This is a breaking change (for subclasses of ChangesListSpecialpage) due to the signature (and name) change of buildMainQueryConds and doMainQuery. An alternative that I don't think is a breaking change would be to put the filter->DB logic in runMainQueryHook, but then it's doing more than just running a hook. This is because it used to only build $conds here, but it's clear from filterOnUserExperienceLevel filters need more than this. I added all the DB parameters from the hook, but this could be debated. I have an checked and fixed the WMF-deployed extensions affected by this. Other than that, there should be full back-compat (including legacy filters not using the new system). * add hidepatrolled/hideunpatrolled to new UI. * Move userExpLevel from RC to ChangesListSpecialPage. Although for now the structured UI only displays on RC anyway, when it displays on watchlist, it seems we'll want userExpLevel there. Change this to make 'all' exclude unregistered users. * Don't have front-end convert none-selected to 'all' on string_options. * Needs the hideanons/hideliu special redirect to be done before this is merged (T151873) Bug: T152754 Bug: T152797 Change-Id: Iec2d82f6a830403d1c948a280efa58992e0cdee7
2017-02-14 07:55:37 +00:00
'associated' => 1,
'invert' => 1
Back-end of new RecentChanges page, refactoring Generate old RC, Related changes (it was already displayed and working on 'Related changes' before this change), and Watchlist/etc. and data for new UI from back-end. This moves everything used for defining the old (unstructured) and new (structured) filters into unified objects, ChangesListFilter and ChangesListFilterGroup (and sub-classes). This includes the query logic (see below) and logic for adding CSS attribution classes. This is a breaking change (for subclasses of ChangesListSpecialpage) due to the signature (and name) change of buildMainQueryConds and doMainQuery. An alternative that I don't think is a breaking change would be to put the filter->DB logic in runMainQueryHook, but then it's doing more than just running a hook. This is because it used to only build $conds here, but it's clear from filterOnUserExperienceLevel filters need more than this. I added all the DB parameters from the hook, but this could be debated. I have an checked and fixed the WMF-deployed extensions affected by this. Other than that, there should be full back-compat (including legacy filters not using the new system). * add hidepatrolled/hideunpatrolled to new UI. * Move userExpLevel from RC to ChangesListSpecialPage. Although for now the structured UI only displays on RC anyway, when it displays on watchlist, it seems we'll want userExpLevel there. Change this to make 'all' exclude unregistered users. * Don't have front-end convert none-selected to 'all' on string_options. * Needs the hideanons/hideliu special redirect to be done before this is merged (T151873) Bug: T152754 Bug: T152797 Change-Id: Iec2d82f6a830403d1c948a280efa58992e0cdee7
2017-02-14 07:55:37 +00:00
],
"rc conditions with multiple namespaces, associated and inverted"
Back-end of new RecentChanges page, refactoring Generate old RC, Related changes (it was already displayed and working on 'Related changes' before this change), and Watchlist/etc. and data for new UI from back-end. This moves everything used for defining the old (unstructured) and new (structured) filters into unified objects, ChangesListFilter and ChangesListFilterGroup (and sub-classes). This includes the query logic (see below) and logic for adding CSS attribution classes. This is a breaking change (for subclasses of ChangesListSpecialpage) due to the signature (and name) change of buildMainQueryConds and doMainQuery. An alternative that I don't think is a breaking change would be to put the filter->DB logic in runMainQueryHook, but then it's doing more than just running a hook. This is because it used to only build $conds here, but it's clear from filterOnUserExperienceLevel filters need more than this. I added all the DB parameters from the hook, but this could be debated. I have an checked and fixed the WMF-deployed extensions affected by this. Other than that, there should be full back-compat (including legacy filters not using the new system). * add hidepatrolled/hideunpatrolled to new UI. * Move userExpLevel from RC to ChangesListSpecialPage. Although for now the structured UI only displays on RC anyway, when it displays on watchlist, it seems we'll want userExpLevel there. Change this to make 'all' exclude unregistered users. * Don't have front-end convert none-selected to 'all' on string_options. * Needs the hideanons/hideliu special redirect to be done before this is merged (T151873) Bug: T152754 Bug: T152797 Change-Id: Iec2d82f6a830403d1c948a280efa58992e0cdee7
2017-02-14 07:55:37 +00:00
);
}
public function testRcNsFilterMultipleInvert() {
$this->assertConditions(
[ # expected
'rc_namespace NOT IN (1,2,3)',
],
[
'namespace' => '1;2;3',
'invert' => 1,
],
"rc conditions with multiple namespaces inverted"
);
Back-end of new RecentChanges page, refactoring Generate old RC, Related changes (it was already displayed and working on 'Related changes' before this change), and Watchlist/etc. and data for new UI from back-end. This moves everything used for defining the old (unstructured) and new (structured) filters into unified objects, ChangesListFilter and ChangesListFilterGroup (and sub-classes). This includes the query logic (see below) and logic for adding CSS attribution classes. This is a breaking change (for subclasses of ChangesListSpecialpage) due to the signature (and name) change of buildMainQueryConds and doMainQuery. An alternative that I don't think is a breaking change would be to put the filter->DB logic in runMainQueryHook, but then it's doing more than just running a hook. This is because it used to only build $conds here, but it's clear from filterOnUserExperienceLevel filters need more than this. I added all the DB parameters from the hook, but this could be debated. I have an checked and fixed the WMF-deployed extensions affected by this. Other than that, there should be full back-compat (including legacy filters not using the new system). * add hidepatrolled/hideunpatrolled to new UI. * Move userExpLevel from RC to ChangesListSpecialPage. Although for now the structured UI only displays on RC anyway, when it displays on watchlist, it seems we'll want userExpLevel there. Change this to make 'all' exclude unregistered users. * Don't have front-end convert none-selected to 'all' on string_options. * Needs the hideanons/hideliu special redirect to be done before this is merged (T151873) Bug: T152754 Bug: T152797 Change-Id: Iec2d82f6a830403d1c948a280efa58992e0cdee7
2017-02-14 07:55:37 +00:00
}
public function testRcNsFilterAllContents() {
$namespaces = $this->getServiceContainer()->getNamespaceInfo()->getSubjectNamespaces();
$this->assertConditions(
[ # expected
'rc_namespace IN (' . $this->getDb()->makeList( $namespaces ) . ')',
],
[
'namespace' => 'all-contents',
],
"rc conditions with all-contents"
);
}
public function testRcNsFilterInvalid() {
$this->assertConditions(
[ # expected
],
[
'namespace' => 'invalid',
],
"rc conditions with invalid namespace"
);
}
public function testRcNsFilterPartialInvalid() {
$namespaces = array_merge(
[ 1 ],
$this->getServiceContainer()->getNamespaceInfo()->getSubjectNamespaces()
);
sort( $namespaces );
$this->assertConditions(
[ # expected
'rc_namespace IN (' . $this->getDb()->makeList( $namespaces ) . ')',
],
[
'namespace' => 'all-contents;1;invalid',
],
"rc conditions with invalid namespace"
);
}
Back-end of new RecentChanges page, refactoring Generate old RC, Related changes (it was already displayed and working on 'Related changes' before this change), and Watchlist/etc. and data for new UI from back-end. This moves everything used for defining the old (unstructured) and new (structured) filters into unified objects, ChangesListFilter and ChangesListFilterGroup (and sub-classes). This includes the query logic (see below) and logic for adding CSS attribution classes. This is a breaking change (for subclasses of ChangesListSpecialpage) due to the signature (and name) change of buildMainQueryConds and doMainQuery. An alternative that I don't think is a breaking change would be to put the filter->DB logic in runMainQueryHook, but then it's doing more than just running a hook. This is because it used to only build $conds here, but it's clear from filterOnUserExperienceLevel filters need more than this. I added all the DB parameters from the hook, but this could be debated. I have an checked and fixed the WMF-deployed extensions affected by this. Other than that, there should be full back-compat (including legacy filters not using the new system). * add hidepatrolled/hideunpatrolled to new UI. * Move userExpLevel from RC to ChangesListSpecialPage. Although for now the structured UI only displays on RC anyway, when it displays on watchlist, it seems we'll want userExpLevel there. Change this to make 'all' exclude unregistered users. * Don't have front-end convert none-selected to 'all' on string_options. * Needs the hideanons/hideliu special redirect to be done before this is merged (T151873) Bug: T152754 Bug: T152797 Change-Id: Iec2d82f6a830403d1c948a280efa58992e0cdee7
2017-02-14 07:55:37 +00:00
public function testRcHidemyselfFilter() {
$user = $this->getTestUser()->getUser();
$this->assertConditions(
[ # expected
$this->getDb()->expr( 'actor_name', '!=', $user->getName() ),
],
[
'hidemyself' => 1,
],
"rc conditions: hidemyself=1 (logged in)",
$user
);
$user = User::newFromName( '10.11.12.13', false );
$this->assertConditions(
[ # expected
"actor_name != '10.11.12.13'",
],
[
'hidemyself' => 1,
],
"rc conditions: hidemyself=1 (anon)",
$user
);
}
Back-end of new RecentChanges page, refactoring Generate old RC, Related changes (it was already displayed and working on 'Related changes' before this change), and Watchlist/etc. and data for new UI from back-end. This moves everything used for defining the old (unstructured) and new (structured) filters into unified objects, ChangesListFilter and ChangesListFilterGroup (and sub-classes). This includes the query logic (see below) and logic for adding CSS attribution classes. This is a breaking change (for subclasses of ChangesListSpecialpage) due to the signature (and name) change of buildMainQueryConds and doMainQuery. An alternative that I don't think is a breaking change would be to put the filter->DB logic in runMainQueryHook, but then it's doing more than just running a hook. This is because it used to only build $conds here, but it's clear from filterOnUserExperienceLevel filters need more than this. I added all the DB parameters from the hook, but this could be debated. I have an checked and fixed the WMF-deployed extensions affected by this. Other than that, there should be full back-compat (including legacy filters not using the new system). * add hidepatrolled/hideunpatrolled to new UI. * Move userExpLevel from RC to ChangesListSpecialPage. Although for now the structured UI only displays on RC anyway, when it displays on watchlist, it seems we'll want userExpLevel there. Change this to make 'all' exclude unregistered users. * Don't have front-end convert none-selected to 'all' on string_options. * Needs the hideanons/hideliu special redirect to be done before this is merged (T151873) Bug: T152754 Bug: T152797 Change-Id: Iec2d82f6a830403d1c948a280efa58992e0cdee7
2017-02-14 07:55:37 +00:00
public function testRcHidebyothersFilter() {
$user = $this->getTestUser()->getUser();
$this->assertConditions(
[ # expected
'actor_user' => $user->getId(),
],
[
'hidebyothers' => 1,
],
"rc conditions: hidebyothers=1 (logged in)",
$user
);
$user = User::newFromName( '10.11.12.13', false );
$this->assertConditions(
[ # expected
'actor_name' => '10.11.12.13',
],
[
'hidebyothers' => 1,
],
"rc conditions: hidebyothers=1 (anon)",
$user
);
}
Back-end of new RecentChanges page, refactoring Generate old RC, Related changes (it was already displayed and working on 'Related changes' before this change), and Watchlist/etc. and data for new UI from back-end. This moves everything used for defining the old (unstructured) and new (structured) filters into unified objects, ChangesListFilter and ChangesListFilterGroup (and sub-classes). This includes the query logic (see below) and logic for adding CSS attribution classes. This is a breaking change (for subclasses of ChangesListSpecialpage) due to the signature (and name) change of buildMainQueryConds and doMainQuery. An alternative that I don't think is a breaking change would be to put the filter->DB logic in runMainQueryHook, but then it's doing more than just running a hook. This is because it used to only build $conds here, but it's clear from filterOnUserExperienceLevel filters need more than this. I added all the DB parameters from the hook, but this could be debated. I have an checked and fixed the WMF-deployed extensions affected by this. Other than that, there should be full back-compat (including legacy filters not using the new system). * add hidepatrolled/hideunpatrolled to new UI. * Move userExpLevel from RC to ChangesListSpecialPage. Although for now the structured UI only displays on RC anyway, when it displays on watchlist, it seems we'll want userExpLevel there. Change this to make 'all' exclude unregistered users. * Don't have front-end convert none-selected to 'all' on string_options. * Needs the hideanons/hideliu special redirect to be done before this is merged (T151873) Bug: T152754 Bug: T152797 Change-Id: Iec2d82f6a830403d1c948a280efa58992e0cdee7
2017-02-14 07:55:37 +00:00
public function testRcHidepageedits() {
$this->assertConditions(
[ # expected
"rc_type != 0",
Back-end of new RecentChanges page, refactoring Generate old RC, Related changes (it was already displayed and working on 'Related changes' before this change), and Watchlist/etc. and data for new UI from back-end. This moves everything used for defining the old (unstructured) and new (structured) filters into unified objects, ChangesListFilter and ChangesListFilterGroup (and sub-classes). This includes the query logic (see below) and logic for adding CSS attribution classes. This is a breaking change (for subclasses of ChangesListSpecialpage) due to the signature (and name) change of buildMainQueryConds and doMainQuery. An alternative that I don't think is a breaking change would be to put the filter->DB logic in runMainQueryHook, but then it's doing more than just running a hook. This is because it used to only build $conds here, but it's clear from filterOnUserExperienceLevel filters need more than this. I added all the DB parameters from the hook, but this could be debated. I have an checked and fixed the WMF-deployed extensions affected by this. Other than that, there should be full back-compat (including legacy filters not using the new system). * add hidepatrolled/hideunpatrolled to new UI. * Move userExpLevel from RC to ChangesListSpecialPage. Although for now the structured UI only displays on RC anyway, when it displays on watchlist, it seems we'll want userExpLevel there. Change this to make 'all' exclude unregistered users. * Don't have front-end convert none-selected to 'all' on string_options. * Needs the hideanons/hideliu special redirect to be done before this is merged (T151873) Bug: T152754 Bug: T152797 Change-Id: Iec2d82f6a830403d1c948a280efa58992e0cdee7
2017-02-14 07:55:37 +00:00
],
[
'hidepageedits' => 1,
],
"rc conditions: hidepageedits=1"
);
}
public function testRcHidenewpages() {
$this->assertConditions(
[ # expected
"rc_type != 1",
Back-end of new RecentChanges page, refactoring Generate old RC, Related changes (it was already displayed and working on 'Related changes' before this change), and Watchlist/etc. and data for new UI from back-end. This moves everything used for defining the old (unstructured) and new (structured) filters into unified objects, ChangesListFilter and ChangesListFilterGroup (and sub-classes). This includes the query logic (see below) and logic for adding CSS attribution classes. This is a breaking change (for subclasses of ChangesListSpecialpage) due to the signature (and name) change of buildMainQueryConds and doMainQuery. An alternative that I don't think is a breaking change would be to put the filter->DB logic in runMainQueryHook, but then it's doing more than just running a hook. This is because it used to only build $conds here, but it's clear from filterOnUserExperienceLevel filters need more than this. I added all the DB parameters from the hook, but this could be debated. I have an checked and fixed the WMF-deployed extensions affected by this. Other than that, there should be full back-compat (including legacy filters not using the new system). * add hidepatrolled/hideunpatrolled to new UI. * Move userExpLevel from RC to ChangesListSpecialPage. Although for now the structured UI only displays on RC anyway, when it displays on watchlist, it seems we'll want userExpLevel there. Change this to make 'all' exclude unregistered users. * Don't have front-end convert none-selected to 'all' on string_options. * Needs the hideanons/hideliu special redirect to be done before this is merged (T151873) Bug: T152754 Bug: T152797 Change-Id: Iec2d82f6a830403d1c948a280efa58992e0cdee7
2017-02-14 07:55:37 +00:00
],
[
'hidenewpages' => 1,
],
"rc conditions: hidenewpages=1"
);
}
public function testRcHidelog() {
$this->assertConditions(
[ # expected
"rc_type != 3",
Back-end of new RecentChanges page, refactoring Generate old RC, Related changes (it was already displayed and working on 'Related changes' before this change), and Watchlist/etc. and data for new UI from back-end. This moves everything used for defining the old (unstructured) and new (structured) filters into unified objects, ChangesListFilter and ChangesListFilterGroup (and sub-classes). This includes the query logic (see below) and logic for adding CSS attribution classes. This is a breaking change (for subclasses of ChangesListSpecialpage) due to the signature (and name) change of buildMainQueryConds and doMainQuery. An alternative that I don't think is a breaking change would be to put the filter->DB logic in runMainQueryHook, but then it's doing more than just running a hook. This is because it used to only build $conds here, but it's clear from filterOnUserExperienceLevel filters need more than this. I added all the DB parameters from the hook, but this could be debated. I have an checked and fixed the WMF-deployed extensions affected by this. Other than that, there should be full back-compat (including legacy filters not using the new system). * add hidepatrolled/hideunpatrolled to new UI. * Move userExpLevel from RC to ChangesListSpecialPage. Although for now the structured UI only displays on RC anyway, when it displays on watchlist, it seems we'll want userExpLevel there. Change this to make 'all' exclude unregistered users. * Don't have front-end convert none-selected to 'all' on string_options. * Needs the hideanons/hideliu special redirect to be done before this is merged (T151873) Bug: T152754 Bug: T152797 Change-Id: Iec2d82f6a830403d1c948a280efa58992e0cdee7
2017-02-14 07:55:37 +00:00
],
[
'hidelog' => 1,
],
"rc conditions: hidelog=1"
);
}
public function testRcHidehumans() {
$this->assertConditions(
[ # expected
'rc_bot' => 1,
],
[
'hidebots' => 0,
'hidehumans' => 1,
],
"rc conditions: hidebots=0 hidehumans=1"
);
}
public function testRcHidepatrolledDisabledFilter() {
$this->overrideConfigValue( MainConfigNames::UseRCPatrol, false );
Back-end of new RecentChanges page, refactoring Generate old RC, Related changes (it was already displayed and working on 'Related changes' before this change), and Watchlist/etc. and data for new UI from back-end. This moves everything used for defining the old (unstructured) and new (structured) filters into unified objects, ChangesListFilter and ChangesListFilterGroup (and sub-classes). This includes the query logic (see below) and logic for adding CSS attribution classes. This is a breaking change (for subclasses of ChangesListSpecialpage) due to the signature (and name) change of buildMainQueryConds and doMainQuery. An alternative that I don't think is a breaking change would be to put the filter->DB logic in runMainQueryHook, but then it's doing more than just running a hook. This is because it used to only build $conds here, but it's clear from filterOnUserExperienceLevel filters need more than this. I added all the DB parameters from the hook, but this could be debated. I have an checked and fixed the WMF-deployed extensions affected by this. Other than that, there should be full back-compat (including legacy filters not using the new system). * add hidepatrolled/hideunpatrolled to new UI. * Move userExpLevel from RC to ChangesListSpecialPage. Although for now the structured UI only displays on RC anyway, when it displays on watchlist, it seems we'll want userExpLevel there. Change this to make 'all' exclude unregistered users. * Don't have front-end convert none-selected to 'all' on string_options. * Needs the hideanons/hideliu special redirect to be done before this is merged (T151873) Bug: T152754 Bug: T152797 Change-Id: Iec2d82f6a830403d1c948a280efa58992e0cdee7
2017-02-14 07:55:37 +00:00
$user = $this->getTestUser()->getUser();
$this->assertConditions(
[ # expected
],
[
'hidepatrolled' => 1,
],
"rc conditions: hidepatrolled=1 (user not allowed)",
$user
);
}
public function testRcHideunpatrolledDisabledFilter() {
$this->overrideConfigValue( MainConfigNames::UseRCPatrol, false );
Back-end of new RecentChanges page, refactoring Generate old RC, Related changes (it was already displayed and working on 'Related changes' before this change), and Watchlist/etc. and data for new UI from back-end. This moves everything used for defining the old (unstructured) and new (structured) filters into unified objects, ChangesListFilter and ChangesListFilterGroup (and sub-classes). This includes the query logic (see below) and logic for adding CSS attribution classes. This is a breaking change (for subclasses of ChangesListSpecialpage) due to the signature (and name) change of buildMainQueryConds and doMainQuery. An alternative that I don't think is a breaking change would be to put the filter->DB logic in runMainQueryHook, but then it's doing more than just running a hook. This is because it used to only build $conds here, but it's clear from filterOnUserExperienceLevel filters need more than this. I added all the DB parameters from the hook, but this could be debated. I have an checked and fixed the WMF-deployed extensions affected by this. Other than that, there should be full back-compat (including legacy filters not using the new system). * add hidepatrolled/hideunpatrolled to new UI. * Move userExpLevel from RC to ChangesListSpecialPage. Although for now the structured UI only displays on RC anyway, when it displays on watchlist, it seems we'll want userExpLevel there. Change this to make 'all' exclude unregistered users. * Don't have front-end convert none-selected to 'all' on string_options. * Needs the hideanons/hideliu special redirect to be done before this is merged (T151873) Bug: T152754 Bug: T152797 Change-Id: Iec2d82f6a830403d1c948a280efa58992e0cdee7
2017-02-14 07:55:37 +00:00
$user = $this->getTestUser()->getUser();
$this->assertConditions(
[ # expected
],
[
'hideunpatrolled' => 1,
],
"rc conditions: hideunpatrolled=1 (user not allowed)",
$user
);
}
Back-end of new RecentChanges page, refactoring Generate old RC, Related changes (it was already displayed and working on 'Related changes' before this change), and Watchlist/etc. and data for new UI from back-end. This moves everything used for defining the old (unstructured) and new (structured) filters into unified objects, ChangesListFilter and ChangesListFilterGroup (and sub-classes). This includes the query logic (see below) and logic for adding CSS attribution classes. This is a breaking change (for subclasses of ChangesListSpecialpage) due to the signature (and name) change of buildMainQueryConds and doMainQuery. An alternative that I don't think is a breaking change would be to put the filter->DB logic in runMainQueryHook, but then it's doing more than just running a hook. This is because it used to only build $conds here, but it's clear from filterOnUserExperienceLevel filters need more than this. I added all the DB parameters from the hook, but this could be debated. I have an checked and fixed the WMF-deployed extensions affected by this. Other than that, there should be full back-compat (including legacy filters not using the new system). * add hidepatrolled/hideunpatrolled to new UI. * Move userExpLevel from RC to ChangesListSpecialPage. Although for now the structured UI only displays on RC anyway, when it displays on watchlist, it seems we'll want userExpLevel there. Change this to make 'all' exclude unregistered users. * Don't have front-end convert none-selected to 'all' on string_options. * Needs the hideanons/hideliu special redirect to be done before this is merged (T151873) Bug: T152754 Bug: T152797 Change-Id: Iec2d82f6a830403d1c948a280efa58992e0cdee7
2017-02-14 07:55:37 +00:00
public function testRcHidepatrolledFilter() {
$user = $this->getTestSysop()->getUser();
$this->assertConditions(
[ # expected
'rc_patrolled' => 0,
Back-end of new RecentChanges page, refactoring Generate old RC, Related changes (it was already displayed and working on 'Related changes' before this change), and Watchlist/etc. and data for new UI from back-end. This moves everything used for defining the old (unstructured) and new (structured) filters into unified objects, ChangesListFilter and ChangesListFilterGroup (and sub-classes). This includes the query logic (see below) and logic for adding CSS attribution classes. This is a breaking change (for subclasses of ChangesListSpecialpage) due to the signature (and name) change of buildMainQueryConds and doMainQuery. An alternative that I don't think is a breaking change would be to put the filter->DB logic in runMainQueryHook, but then it's doing more than just running a hook. This is because it used to only build $conds here, but it's clear from filterOnUserExperienceLevel filters need more than this. I added all the DB parameters from the hook, but this could be debated. I have an checked and fixed the WMF-deployed extensions affected by this. Other than that, there should be full back-compat (including legacy filters not using the new system). * add hidepatrolled/hideunpatrolled to new UI. * Move userExpLevel from RC to ChangesListSpecialPage. Although for now the structured UI only displays on RC anyway, when it displays on watchlist, it seems we'll want userExpLevel there. Change this to make 'all' exclude unregistered users. * Don't have front-end convert none-selected to 'all' on string_options. * Needs the hideanons/hideliu special redirect to be done before this is merged (T151873) Bug: T152754 Bug: T152797 Change-Id: Iec2d82f6a830403d1c948a280efa58992e0cdee7
2017-02-14 07:55:37 +00:00
],
[
'hidepatrolled' => 1,
],
"rc conditions: hidepatrolled=1",
$user
);
}
public function testRcHideunpatrolledFilter() {
$user = $this->getTestSysop()->getUser();
$this->assertConditions(
[ # expected
'rc_patrolled' => [ 1, 2 ],
Back-end of new RecentChanges page, refactoring Generate old RC, Related changes (it was already displayed and working on 'Related changes' before this change), and Watchlist/etc. and data for new UI from back-end. This moves everything used for defining the old (unstructured) and new (structured) filters into unified objects, ChangesListFilter and ChangesListFilterGroup (and sub-classes). This includes the query logic (see below) and logic for adding CSS attribution classes. This is a breaking change (for subclasses of ChangesListSpecialpage) due to the signature (and name) change of buildMainQueryConds and doMainQuery. An alternative that I don't think is a breaking change would be to put the filter->DB logic in runMainQueryHook, but then it's doing more than just running a hook. This is because it used to only build $conds here, but it's clear from filterOnUserExperienceLevel filters need more than this. I added all the DB parameters from the hook, but this could be debated. I have an checked and fixed the WMF-deployed extensions affected by this. Other than that, there should be full back-compat (including legacy filters not using the new system). * add hidepatrolled/hideunpatrolled to new UI. * Move userExpLevel from RC to ChangesListSpecialPage. Although for now the structured UI only displays on RC anyway, when it displays on watchlist, it seems we'll want userExpLevel there. Change this to make 'all' exclude unregistered users. * Don't have front-end convert none-selected to 'all' on string_options. * Needs the hideanons/hideliu special redirect to be done before this is merged (T151873) Bug: T152754 Bug: T152797 Change-Id: Iec2d82f6a830403d1c948a280efa58992e0cdee7
2017-02-14 07:55:37 +00:00
],
[
'hideunpatrolled' => 1,
],
"rc conditions: hideunpatrolled=1",
$user
);
}
public function testRcReviewStatusFilter() {
$user = $this->getTestSysop()->getUser();
$this->assertConditions(
[ # expected
'rc_patrolled' => 1,
],
[
'reviewStatus' => 'manual'
],
"rc conditions: reviewStatus=manual",
$user
);
$this->assertConditions(
[ # expected
'rc_patrolled' => [ 0, 2 ],
],
[
'reviewStatus' => 'unpatrolled;auto'
],
"rc conditions: reviewStatus=unpatrolled;auto",
$user
);
}
Back-end of new RecentChanges page, refactoring Generate old RC, Related changes (it was already displayed and working on 'Related changes' before this change), and Watchlist/etc. and data for new UI from back-end. This moves everything used for defining the old (unstructured) and new (structured) filters into unified objects, ChangesListFilter and ChangesListFilterGroup (and sub-classes). This includes the query logic (see below) and logic for adding CSS attribution classes. This is a breaking change (for subclasses of ChangesListSpecialpage) due to the signature (and name) change of buildMainQueryConds and doMainQuery. An alternative that I don't think is a breaking change would be to put the filter->DB logic in runMainQueryHook, but then it's doing more than just running a hook. This is because it used to only build $conds here, but it's clear from filterOnUserExperienceLevel filters need more than this. I added all the DB parameters from the hook, but this could be debated. I have an checked and fixed the WMF-deployed extensions affected by this. Other than that, there should be full back-compat (including legacy filters not using the new system). * add hidepatrolled/hideunpatrolled to new UI. * Move userExpLevel from RC to ChangesListSpecialPage. Although for now the structured UI only displays on RC anyway, when it displays on watchlist, it seems we'll want userExpLevel there. Change this to make 'all' exclude unregistered users. * Don't have front-end convert none-selected to 'all' on string_options. * Needs the hideanons/hideliu special redirect to be done before this is merged (T151873) Bug: T152754 Bug: T152797 Change-Id: Iec2d82f6a830403d1c948a280efa58992e0cdee7
2017-02-14 07:55:37 +00:00
public function testRcHideminorFilter() {
$this->assertConditions(
[ # expected
'rc_minor = 0',
Back-end of new RecentChanges page, refactoring Generate old RC, Related changes (it was already displayed and working on 'Related changes' before this change), and Watchlist/etc. and data for new UI from back-end. This moves everything used for defining the old (unstructured) and new (structured) filters into unified objects, ChangesListFilter and ChangesListFilterGroup (and sub-classes). This includes the query logic (see below) and logic for adding CSS attribution classes. This is a breaking change (for subclasses of ChangesListSpecialpage) due to the signature (and name) change of buildMainQueryConds and doMainQuery. An alternative that I don't think is a breaking change would be to put the filter->DB logic in runMainQueryHook, but then it's doing more than just running a hook. This is because it used to only build $conds here, but it's clear from filterOnUserExperienceLevel filters need more than this. I added all the DB parameters from the hook, but this could be debated. I have an checked and fixed the WMF-deployed extensions affected by this. Other than that, there should be full back-compat (including legacy filters not using the new system). * add hidepatrolled/hideunpatrolled to new UI. * Move userExpLevel from RC to ChangesListSpecialPage. Although for now the structured UI only displays on RC anyway, when it displays on watchlist, it seems we'll want userExpLevel there. Change this to make 'all' exclude unregistered users. * Don't have front-end convert none-selected to 'all' on string_options. * Needs the hideanons/hideliu special redirect to be done before this is merged (T151873) Bug: T152754 Bug: T152797 Change-Id: Iec2d82f6a830403d1c948a280efa58992e0cdee7
2017-02-14 07:55:37 +00:00
],
[
'hideminor' => 1,
],
"rc conditions: hideminor=1"
);
}
public function testRcHidemajorFilter() {
$this->assertConditions(
[ # expected
'rc_minor = 1',
Back-end of new RecentChanges page, refactoring Generate old RC, Related changes (it was already displayed and working on 'Related changes' before this change), and Watchlist/etc. and data for new UI from back-end. This moves everything used for defining the old (unstructured) and new (structured) filters into unified objects, ChangesListFilter and ChangesListFilterGroup (and sub-classes). This includes the query logic (see below) and logic for adding CSS attribution classes. This is a breaking change (for subclasses of ChangesListSpecialpage) due to the signature (and name) change of buildMainQueryConds and doMainQuery. An alternative that I don't think is a breaking change would be to put the filter->DB logic in runMainQueryHook, but then it's doing more than just running a hook. This is because it used to only build $conds here, but it's clear from filterOnUserExperienceLevel filters need more than this. I added all the DB parameters from the hook, but this could be debated. I have an checked and fixed the WMF-deployed extensions affected by this. Other than that, there should be full back-compat (including legacy filters not using the new system). * add hidepatrolled/hideunpatrolled to new UI. * Move userExpLevel from RC to ChangesListSpecialPage. Although for now the structured UI only displays on RC anyway, when it displays on watchlist, it seems we'll want userExpLevel there. Change this to make 'all' exclude unregistered users. * Don't have front-end convert none-selected to 'all' on string_options. * Needs the hideanons/hideliu special redirect to be done before this is merged (T151873) Bug: T152754 Bug: T152797 Change-Id: Iec2d82f6a830403d1c948a280efa58992e0cdee7
2017-02-14 07:55:37 +00:00
],
[
'hidemajor' => 1,
],
"rc conditions: hidemajor=1"
);
}
public function testHideCategorization() {
$this->assertConditions(
[
# expected
"rc_type != 6"
Back-end of new RecentChanges page, refactoring Generate old RC, Related changes (it was already displayed and working on 'Related changes' before this change), and Watchlist/etc. and data for new UI from back-end. This moves everything used for defining the old (unstructured) and new (structured) filters into unified objects, ChangesListFilter and ChangesListFilterGroup (and sub-classes). This includes the query logic (see below) and logic for adding CSS attribution classes. This is a breaking change (for subclasses of ChangesListSpecialpage) due to the signature (and name) change of buildMainQueryConds and doMainQuery. An alternative that I don't think is a breaking change would be to put the filter->DB logic in runMainQueryHook, but then it's doing more than just running a hook. This is because it used to only build $conds here, but it's clear from filterOnUserExperienceLevel filters need more than this. I added all the DB parameters from the hook, but this could be debated. I have an checked and fixed the WMF-deployed extensions affected by this. Other than that, there should be full back-compat (including legacy filters not using the new system). * add hidepatrolled/hideunpatrolled to new UI. * Move userExpLevel from RC to ChangesListSpecialPage. Although for now the structured UI only displays on RC anyway, when it displays on watchlist, it seems we'll want userExpLevel there. Change this to make 'all' exclude unregistered users. * Don't have front-end convert none-selected to 'all' on string_options. * Needs the hideanons/hideliu special redirect to be done before this is merged (T151873) Bug: T152754 Bug: T152797 Change-Id: Iec2d82f6a830403d1c948a280efa58992e0cdee7
2017-02-14 07:55:37 +00:00
],
[
'hidecategorization' => 1
],
"rc conditions: hidecategorization=1"
);
}
Support multiple matchPatterns in temp user autocreate config Why: * There is a need to update the generation and match pattern on WMF wikis to a new format that includes the year and starts with `~`. As such, the 'matchPattern' key needs to be updated. * Removing the old 'matchPattern' from the wgAutoCreateTempUser config currently leaves existing temporary accounts as no longer recongnised as temporary accounts. * Instead, the 'matchPattern' needs to be able to take an array of string patterns so that old patterns can still be used for matching. What: * Update the MainConfigSchama to indicate that 'matchPattern' in the wgAutoCreateTempUser config can be an array of strings. * Add TempUserConfig::getMatchPatterns and deprecate TempUserConfig:: getMatchPattern. This is needed because ::getMatchPattern was typed to only ever return one Pattern, which is no longer the case with this config change. * Update the RealTempUserConfig to support multiple patterns defined in the 'matchPattern' key. The RealTempUserConfig::getMatchPattern method returns the pattern or first pattern if multiple are defined to allow time for existing usages of this deprecated method to be updated. * Update the RealTempUserConfig to rely on other methods instead of checking object property values where possible (e.g. use ::isEnabled instead of checking $this->enabled) to allow easier unit testing. * Update UserSelectQueryBuilder and ChangesListSpecialPage to use TempUserConfig ::getMatchPatterns instead of ::getMatchPattern. * Update mediawiki.util/util.js to be able to parse the 'matchPattern' value when it is an array of strings. * Update maintenance/userOptions.php to use ::getMatchPatterns instead of ::getMatchPattern. * Add and update unit and integration tests for the new code, as well as expanding coverage over existing code that was indirectly affected. Bug: T354619 Change-Id: I3763daefe4dc7c76370bd934fb20452591c9c762
2024-01-10 23:40:27 +00:00
/** @see TempUserTestTrait::enableAutoCreateTempUser */
protected function enableAutoCreateTempUser( array $configOverrides = [] ): void {
$this->_enableAutoCreateTempUser( $configOverrides );
$this->changesListSpecialPage->setTempUserConfig( $this->getServiceContainer()->getTempUserConfig() );
}
/** @see TempUserTestTrait::disableAutoCreateTempUser */
protected function disableAutoCreateTempUser( array $configOverrides = [] ): void {
$this->_disableAutoCreateTempUser( $configOverrides );
Support multiple matchPatterns in temp user autocreate config Why: * There is a need to update the generation and match pattern on WMF wikis to a new format that includes the year and starts with `~`. As such, the 'matchPattern' key needs to be updated. * Removing the old 'matchPattern' from the wgAutoCreateTempUser config currently leaves existing temporary accounts as no longer recongnised as temporary accounts. * Instead, the 'matchPattern' needs to be able to take an array of string patterns so that old patterns can still be used for matching. What: * Update the MainConfigSchama to indicate that 'matchPattern' in the wgAutoCreateTempUser config can be an array of strings. * Add TempUserConfig::getMatchPatterns and deprecate TempUserConfig:: getMatchPattern. This is needed because ::getMatchPattern was typed to only ever return one Pattern, which is no longer the case with this config change. * Update the RealTempUserConfig to support multiple patterns defined in the 'matchPattern' key. The RealTempUserConfig::getMatchPattern method returns the pattern or first pattern if multiple are defined to allow time for existing usages of this deprecated method to be updated. * Update the RealTempUserConfig to rely on other methods instead of checking object property values where possible (e.g. use ::isEnabled instead of checking $this->enabled) to allow easier unit testing. * Update UserSelectQueryBuilder and ChangesListSpecialPage to use TempUserConfig ::getMatchPatterns instead of ::getMatchPattern. * Update mediawiki.util/util.js to be able to parse the 'matchPattern' value when it is an array of strings. * Update maintenance/userOptions.php to use ::getMatchPatterns instead of ::getMatchPattern. * Add and update unit and integration tests for the new code, as well as expanding coverage over existing code that was indirectly affected. Bug: T354619 Change-Id: I3763daefe4dc7c76370bd934fb20452591c9c762
2024-01-10 23:40:27 +00:00
$this->changesListSpecialPage->setTempUserConfig( $this->getServiceContainer()->getTempUserConfig() );
}
public function testRegistrationHideliu() {
$this->enableAutoCreateTempUser();
$tempUserMatchPattern = $this->getServiceContainer()->getTempUserConfig()
->getMatchCondition( $this->getDb(), 'actor_name', IExpression::LIKE )
->toSql( $this->getDb() );
$this->assertConditions(
[
"((actor_user IS NULL OR $tempUserMatchPattern))",
],
[
'hideliu' => 1,
],
"rc conditions: hideliu=1"
);
}
public function testRegistrationHideanons() {
$this->enableAutoCreateTempUser();
$tempUserMatchPattern = $this->getServiceContainer()->getTempUserConfig()
->getMatchCondition( $this->getDb(), 'actor_name', IExpression::NOT_LIKE )
->toSql( $this->getDb() );
$this->assertConditions(
[
"((actor_user IS NOT NULL AND $tempUserMatchPattern))",
],
[
'hideanons' => 1,
],
"rc conditions: hideanons=1"
);
}
public function testFilterUserExpLevelAll() {
$this->assertConditions(
[
# expected
],
[
'userExpLevel' => 'registered;unregistered;newcomer;learner;experienced',
],
"rc conditions: userExpLevel=registered;unregistered;newcomer;learner;experienced"
);
}
public function testFilterUserExpLevelRegisteredUnregistered() {
$this->assertConditions(
[
# expected
],
[
'userExpLevel' => 'registered;unregistered',
],
"rc conditions: userExpLevel=registered;unregistered"
);
}
public function testFilterUserExpLevelRegisteredUnregisteredLearner() {
$this->assertConditions(
[
# expected
],
[
'userExpLevel' => 'registered;unregistered;learner',
],
"rc conditions: userExpLevel=registered;unregistered;learner"
);
}
public function testFilterUserExpLevelAllExperienceLevels() {
Support multiple matchPatterns in temp user autocreate config Why: * There is a need to update the generation and match pattern on WMF wikis to a new format that includes the year and starts with `~`. As such, the 'matchPattern' key needs to be updated. * Removing the old 'matchPattern' from the wgAutoCreateTempUser config currently leaves existing temporary accounts as no longer recongnised as temporary accounts. * Instead, the 'matchPattern' needs to be able to take an array of string patterns so that old patterns can still be used for matching. What: * Update the MainConfigSchama to indicate that 'matchPattern' in the wgAutoCreateTempUser config can be an array of strings. * Add TempUserConfig::getMatchPatterns and deprecate TempUserConfig:: getMatchPattern. This is needed because ::getMatchPattern was typed to only ever return one Pattern, which is no longer the case with this config change. * Update the RealTempUserConfig to support multiple patterns defined in the 'matchPattern' key. The RealTempUserConfig::getMatchPattern method returns the pattern or first pattern if multiple are defined to allow time for existing usages of this deprecated method to be updated. * Update the RealTempUserConfig to rely on other methods instead of checking object property values where possible (e.g. use ::isEnabled instead of checking $this->enabled) to allow easier unit testing. * Update UserSelectQueryBuilder and ChangesListSpecialPage to use TempUserConfig ::getMatchPatterns instead of ::getMatchPattern. * Update mediawiki.util/util.js to be able to parse the 'matchPattern' value when it is an array of strings. * Update maintenance/userOptions.php to use ::getMatchPatterns instead of ::getMatchPattern. * Add and update unit and integration tests for the new code, as well as expanding coverage over existing code that was indirectly affected. Bug: T354619 Change-Id: I3763daefe4dc7c76370bd934fb20452591c9c762
2024-01-10 23:40:27 +00:00
$this->disableAutoCreateTempUser();
$this->assertConditions(
[
# expected
'(actor_user IS NOT NULL)',
],
[
'userExpLevel' => 'newcomer;learner;experienced',
],
"rc conditions: userExpLevel=newcomer;learner;experienced"
);
}
public function testFilterUserExpLevelRegistered() {
Support multiple matchPatterns in temp user autocreate config Why: * There is a need to update the generation and match pattern on WMF wikis to a new format that includes the year and starts with `~`. As such, the 'matchPattern' key needs to be updated. * Removing the old 'matchPattern' from the wgAutoCreateTempUser config currently leaves existing temporary accounts as no longer recongnised as temporary accounts. * Instead, the 'matchPattern' needs to be able to take an array of string patterns so that old patterns can still be used for matching. What: * Update the MainConfigSchama to indicate that 'matchPattern' in the wgAutoCreateTempUser config can be an array of strings. * Add TempUserConfig::getMatchPatterns and deprecate TempUserConfig:: getMatchPattern. This is needed because ::getMatchPattern was typed to only ever return one Pattern, which is no longer the case with this config change. * Update the RealTempUserConfig to support multiple patterns defined in the 'matchPattern' key. The RealTempUserConfig::getMatchPattern method returns the pattern or first pattern if multiple are defined to allow time for existing usages of this deprecated method to be updated. * Update the RealTempUserConfig to rely on other methods instead of checking object property values where possible (e.g. use ::isEnabled instead of checking $this->enabled) to allow easier unit testing. * Update UserSelectQueryBuilder and ChangesListSpecialPage to use TempUserConfig ::getMatchPatterns instead of ::getMatchPattern. * Update mediawiki.util/util.js to be able to parse the 'matchPattern' value when it is an array of strings. * Update maintenance/userOptions.php to use ::getMatchPatterns instead of ::getMatchPattern. * Add and update unit and integration tests for the new code, as well as expanding coverage over existing code that was indirectly affected. Bug: T354619 Change-Id: I3763daefe4dc7c76370bd934fb20452591c9c762
2024-01-10 23:40:27 +00:00
$this->disableAutoCreateTempUser();
$this->assertConditions(
[
# expected
'(actor_user IS NOT NULL)',
],
[
'userExpLevel' => 'registered',
],
"rc conditions: userExpLevel=registered"
);
}
Support multiple matchPatterns in temp user autocreate config Why: * There is a need to update the generation and match pattern on WMF wikis to a new format that includes the year and starts with `~`. As such, the 'matchPattern' key needs to be updated. * Removing the old 'matchPattern' from the wgAutoCreateTempUser config currently leaves existing temporary accounts as no longer recongnised as temporary accounts. * Instead, the 'matchPattern' needs to be able to take an array of string patterns so that old patterns can still be used for matching. What: * Update the MainConfigSchama to indicate that 'matchPattern' in the wgAutoCreateTempUser config can be an array of strings. * Add TempUserConfig::getMatchPatterns and deprecate TempUserConfig:: getMatchPattern. This is needed because ::getMatchPattern was typed to only ever return one Pattern, which is no longer the case with this config change. * Update the RealTempUserConfig to support multiple patterns defined in the 'matchPattern' key. The RealTempUserConfig::getMatchPattern method returns the pattern or first pattern if multiple are defined to allow time for existing usages of this deprecated method to be updated. * Update the RealTempUserConfig to rely on other methods instead of checking object property values where possible (e.g. use ::isEnabled instead of checking $this->enabled) to allow easier unit testing. * Update UserSelectQueryBuilder and ChangesListSpecialPage to use TempUserConfig ::getMatchPatterns instead of ::getMatchPattern. * Update mediawiki.util/util.js to be able to parse the 'matchPattern' value when it is an array of strings. * Update maintenance/userOptions.php to use ::getMatchPatterns instead of ::getMatchPattern. * Add and update unit and integration tests for the new code, as well as expanding coverage over existing code that was indirectly affected. Bug: T354619 Change-Id: I3763daefe4dc7c76370bd934fb20452591c9c762
2024-01-10 23:40:27 +00:00
public function testFilterUserExpLevelRegisteredTempAccountsEnabled() {
$this->enableAutoCreateTempUser();
$tempUserMatchPattern = $this->getServiceContainer()->getTempUserConfig()
->getMatchCondition( $this->getDb(), 'actor_name', IExpression::NOT_LIKE )
->toSql( $this->getDb() );
Support multiple matchPatterns in temp user autocreate config Why: * There is a need to update the generation and match pattern on WMF wikis to a new format that includes the year and starts with `~`. As such, the 'matchPattern' key needs to be updated. * Removing the old 'matchPattern' from the wgAutoCreateTempUser config currently leaves existing temporary accounts as no longer recongnised as temporary accounts. * Instead, the 'matchPattern' needs to be able to take an array of string patterns so that old patterns can still be used for matching. What: * Update the MainConfigSchama to indicate that 'matchPattern' in the wgAutoCreateTempUser config can be an array of strings. * Add TempUserConfig::getMatchPatterns and deprecate TempUserConfig:: getMatchPattern. This is needed because ::getMatchPattern was typed to only ever return one Pattern, which is no longer the case with this config change. * Update the RealTempUserConfig to support multiple patterns defined in the 'matchPattern' key. The RealTempUserConfig::getMatchPattern method returns the pattern or first pattern if multiple are defined to allow time for existing usages of this deprecated method to be updated. * Update the RealTempUserConfig to rely on other methods instead of checking object property values where possible (e.g. use ::isEnabled instead of checking $this->enabled) to allow easier unit testing. * Update UserSelectQueryBuilder and ChangesListSpecialPage to use TempUserConfig ::getMatchPatterns instead of ::getMatchPattern. * Update mediawiki.util/util.js to be able to parse the 'matchPattern' value when it is an array of strings. * Update maintenance/userOptions.php to use ::getMatchPatterns instead of ::getMatchPattern. * Add and update unit and integration tests for the new code, as well as expanding coverage over existing code that was indirectly affected. Bug: T354619 Change-Id: I3763daefe4dc7c76370bd934fb20452591c9c762
2024-01-10 23:40:27 +00:00
$this->assertConditions(
[
# expected
"((actor_user IS NOT NULL AND $tempUserMatchPattern))",
Support multiple matchPatterns in temp user autocreate config Why: * There is a need to update the generation and match pattern on WMF wikis to a new format that includes the year and starts with `~`. As such, the 'matchPattern' key needs to be updated. * Removing the old 'matchPattern' from the wgAutoCreateTempUser config currently leaves existing temporary accounts as no longer recongnised as temporary accounts. * Instead, the 'matchPattern' needs to be able to take an array of string patterns so that old patterns can still be used for matching. What: * Update the MainConfigSchama to indicate that 'matchPattern' in the wgAutoCreateTempUser config can be an array of strings. * Add TempUserConfig::getMatchPatterns and deprecate TempUserConfig:: getMatchPattern. This is needed because ::getMatchPattern was typed to only ever return one Pattern, which is no longer the case with this config change. * Update the RealTempUserConfig to support multiple patterns defined in the 'matchPattern' key. The RealTempUserConfig::getMatchPattern method returns the pattern or first pattern if multiple are defined to allow time for existing usages of this deprecated method to be updated. * Update the RealTempUserConfig to rely on other methods instead of checking object property values where possible (e.g. use ::isEnabled instead of checking $this->enabled) to allow easier unit testing. * Update UserSelectQueryBuilder and ChangesListSpecialPage to use TempUserConfig ::getMatchPatterns instead of ::getMatchPattern. * Update mediawiki.util/util.js to be able to parse the 'matchPattern' value when it is an array of strings. * Update maintenance/userOptions.php to use ::getMatchPatterns instead of ::getMatchPattern. * Add and update unit and integration tests for the new code, as well as expanding coverage over existing code that was indirectly affected. Bug: T354619 Change-Id: I3763daefe4dc7c76370bd934fb20452591c9c762
2024-01-10 23:40:27 +00:00
],
[
'userExpLevel' => 'registered',
],
"rc conditions: userExpLevel=registered"
);
}
public function testFilterUserExpLevelUnregistered() {
Support multiple matchPatterns in temp user autocreate config Why: * There is a need to update the generation and match pattern on WMF wikis to a new format that includes the year and starts with `~`. As such, the 'matchPattern' key needs to be updated. * Removing the old 'matchPattern' from the wgAutoCreateTempUser config currently leaves existing temporary accounts as no longer recongnised as temporary accounts. * Instead, the 'matchPattern' needs to be able to take an array of string patterns so that old patterns can still be used for matching. What: * Update the MainConfigSchama to indicate that 'matchPattern' in the wgAutoCreateTempUser config can be an array of strings. * Add TempUserConfig::getMatchPatterns and deprecate TempUserConfig:: getMatchPattern. This is needed because ::getMatchPattern was typed to only ever return one Pattern, which is no longer the case with this config change. * Update the RealTempUserConfig to support multiple patterns defined in the 'matchPattern' key. The RealTempUserConfig::getMatchPattern method returns the pattern or first pattern if multiple are defined to allow time for existing usages of this deprecated method to be updated. * Update the RealTempUserConfig to rely on other methods instead of checking object property values where possible (e.g. use ::isEnabled instead of checking $this->enabled) to allow easier unit testing. * Update UserSelectQueryBuilder and ChangesListSpecialPage to use TempUserConfig ::getMatchPatterns instead of ::getMatchPattern. * Update mediawiki.util/util.js to be able to parse the 'matchPattern' value when it is an array of strings. * Update maintenance/userOptions.php to use ::getMatchPatterns instead of ::getMatchPattern. * Add and update unit and integration tests for the new code, as well as expanding coverage over existing code that was indirectly affected. Bug: T354619 Change-Id: I3763daefe4dc7c76370bd934fb20452591c9c762
2024-01-10 23:40:27 +00:00
$this->disableAutoCreateTempUser();
$this->assertConditions(
[
# expected
'(actor_user IS NULL)'
],
[
'userExpLevel' => 'unregistered',
],
"rc conditions: userExpLevel=unregistered"
);
}
Support multiple matchPatterns in temp user autocreate config Why: * There is a need to update the generation and match pattern on WMF wikis to a new format that includes the year and starts with `~`. As such, the 'matchPattern' key needs to be updated. * Removing the old 'matchPattern' from the wgAutoCreateTempUser config currently leaves existing temporary accounts as no longer recongnised as temporary accounts. * Instead, the 'matchPattern' needs to be able to take an array of string patterns so that old patterns can still be used for matching. What: * Update the MainConfigSchama to indicate that 'matchPattern' in the wgAutoCreateTempUser config can be an array of strings. * Add TempUserConfig::getMatchPatterns and deprecate TempUserConfig:: getMatchPattern. This is needed because ::getMatchPattern was typed to only ever return one Pattern, which is no longer the case with this config change. * Update the RealTempUserConfig to support multiple patterns defined in the 'matchPattern' key. The RealTempUserConfig::getMatchPattern method returns the pattern or first pattern if multiple are defined to allow time for existing usages of this deprecated method to be updated. * Update the RealTempUserConfig to rely on other methods instead of checking object property values where possible (e.g. use ::isEnabled instead of checking $this->enabled) to allow easier unit testing. * Update UserSelectQueryBuilder and ChangesListSpecialPage to use TempUserConfig ::getMatchPatterns instead of ::getMatchPattern. * Update mediawiki.util/util.js to be able to parse the 'matchPattern' value when it is an array of strings. * Update maintenance/userOptions.php to use ::getMatchPatterns instead of ::getMatchPattern. * Add and update unit and integration tests for the new code, as well as expanding coverage over existing code that was indirectly affected. Bug: T354619 Change-Id: I3763daefe4dc7c76370bd934fb20452591c9c762
2024-01-10 23:40:27 +00:00
public function testFilterUserExpLevelUnregisteredTempAccountsEnabled() {
$this->enableAutoCreateTempUser();
$tempUserMatchPattern = $this->getServiceContainer()->getTempUserConfig()
->getMatchCondition( $this->getDb(), 'actor_name', IExpression::LIKE )
->toSql( $this->getDb() );
Support multiple matchPatterns in temp user autocreate config Why: * There is a need to update the generation and match pattern on WMF wikis to a new format that includes the year and starts with `~`. As such, the 'matchPattern' key needs to be updated. * Removing the old 'matchPattern' from the wgAutoCreateTempUser config currently leaves existing temporary accounts as no longer recongnised as temporary accounts. * Instead, the 'matchPattern' needs to be able to take an array of string patterns so that old patterns can still be used for matching. What: * Update the MainConfigSchama to indicate that 'matchPattern' in the wgAutoCreateTempUser config can be an array of strings. * Add TempUserConfig::getMatchPatterns and deprecate TempUserConfig:: getMatchPattern. This is needed because ::getMatchPattern was typed to only ever return one Pattern, which is no longer the case with this config change. * Update the RealTempUserConfig to support multiple patterns defined in the 'matchPattern' key. The RealTempUserConfig::getMatchPattern method returns the pattern or first pattern if multiple are defined to allow time for existing usages of this deprecated method to be updated. * Update the RealTempUserConfig to rely on other methods instead of checking object property values where possible (e.g. use ::isEnabled instead of checking $this->enabled) to allow easier unit testing. * Update UserSelectQueryBuilder and ChangesListSpecialPage to use TempUserConfig ::getMatchPatterns instead of ::getMatchPattern. * Update mediawiki.util/util.js to be able to parse the 'matchPattern' value when it is an array of strings. * Update maintenance/userOptions.php to use ::getMatchPatterns instead of ::getMatchPattern. * Add and update unit and integration tests for the new code, as well as expanding coverage over existing code that was indirectly affected. Bug: T354619 Change-Id: I3763daefe4dc7c76370bd934fb20452591c9c762
2024-01-10 23:40:27 +00:00
$this->assertConditions(
[
# expected
"((actor_user IS NULL OR $tempUserMatchPattern))",
Support multiple matchPatterns in temp user autocreate config Why: * There is a need to update the generation and match pattern on WMF wikis to a new format that includes the year and starts with `~`. As such, the 'matchPattern' key needs to be updated. * Removing the old 'matchPattern' from the wgAutoCreateTempUser config currently leaves existing temporary accounts as no longer recongnised as temporary accounts. * Instead, the 'matchPattern' needs to be able to take an array of string patterns so that old patterns can still be used for matching. What: * Update the MainConfigSchama to indicate that 'matchPattern' in the wgAutoCreateTempUser config can be an array of strings. * Add TempUserConfig::getMatchPatterns and deprecate TempUserConfig:: getMatchPattern. This is needed because ::getMatchPattern was typed to only ever return one Pattern, which is no longer the case with this config change. * Update the RealTempUserConfig to support multiple patterns defined in the 'matchPattern' key. The RealTempUserConfig::getMatchPattern method returns the pattern or first pattern if multiple are defined to allow time for existing usages of this deprecated method to be updated. * Update the RealTempUserConfig to rely on other methods instead of checking object property values where possible (e.g. use ::isEnabled instead of checking $this->enabled) to allow easier unit testing. * Update UserSelectQueryBuilder and ChangesListSpecialPage to use TempUserConfig ::getMatchPatterns instead of ::getMatchPattern. * Update mediawiki.util/util.js to be able to parse the 'matchPattern' value when it is an array of strings. * Update maintenance/userOptions.php to use ::getMatchPatterns instead of ::getMatchPattern. * Add and update unit and integration tests for the new code, as well as expanding coverage over existing code that was indirectly affected. Bug: T354619 Change-Id: I3763daefe4dc7c76370bd934fb20452591c9c762
2024-01-10 23:40:27 +00:00
],
[
'userExpLevel' => 'unregistered',
],
"rc conditions: userExpLevel=unregistered"
);
}
public function testFilterUserExpLevelRegisteredOrLearner() {
Support multiple matchPatterns in temp user autocreate config Why: * There is a need to update the generation and match pattern on WMF wikis to a new format that includes the year and starts with `~`. As such, the 'matchPattern' key needs to be updated. * Removing the old 'matchPattern' from the wgAutoCreateTempUser config currently leaves existing temporary accounts as no longer recongnised as temporary accounts. * Instead, the 'matchPattern' needs to be able to take an array of string patterns so that old patterns can still be used for matching. What: * Update the MainConfigSchama to indicate that 'matchPattern' in the wgAutoCreateTempUser config can be an array of strings. * Add TempUserConfig::getMatchPatterns and deprecate TempUserConfig:: getMatchPattern. This is needed because ::getMatchPattern was typed to only ever return one Pattern, which is no longer the case with this config change. * Update the RealTempUserConfig to support multiple patterns defined in the 'matchPattern' key. The RealTempUserConfig::getMatchPattern method returns the pattern or first pattern if multiple are defined to allow time for existing usages of this deprecated method to be updated. * Update the RealTempUserConfig to rely on other methods instead of checking object property values where possible (e.g. use ::isEnabled instead of checking $this->enabled) to allow easier unit testing. * Update UserSelectQueryBuilder and ChangesListSpecialPage to use TempUserConfig ::getMatchPatterns instead of ::getMatchPattern. * Update mediawiki.util/util.js to be able to parse the 'matchPattern' value when it is an array of strings. * Update maintenance/userOptions.php to use ::getMatchPatterns instead of ::getMatchPattern. * Add and update unit and integration tests for the new code, as well as expanding coverage over existing code that was indirectly affected. Bug: T354619 Change-Id: I3763daefe4dc7c76370bd934fb20452591c9c762
2024-01-10 23:40:27 +00:00
$this->disableAutoCreateTempUser();
$this->assertConditions(
[
# expected
'(actor_user IS NOT NULL)',
],
[
'userExpLevel' => 'registered;learner',
],
"rc conditions: userExpLevel=registered;learner"
);
}
public function testFilterUserExpLevelLearner() {
$this->disableAutoCreateTempUser();
ConvertibleTimestamp::setFakeTime( '20201231000000' );
$this->assertConditions(
[
# expected
"((actor_user IS NOT NULL AND "
. "(user_editcount >= 10 AND (user_registration IS NULL OR user_registration <= '{$this->getDb()->timestamp( '20201227000000' )}')) AND "
. "(user_editcount < 500 OR user_registration > '{$this->getDb()->timestamp( '20201201000000' )}')"
. "))"
],
[
'userExpLevel' => 'learner'
],
"rc conditions: userExpLevel=learner"
);
}
public function testFilterUserExpLevelLearnerWhenTemporaryAccountsEnabled() {
$this->enableAutoCreateTempUser();
ConvertibleTimestamp::setFakeTime( '20201231000000' );
$notLikeTempUserMatchExpression = $this->getServiceContainer()->getTempUserConfig()
->getMatchCondition( $this->getDb(), 'actor_name', IExpression::NOT_LIKE )
->toSql( $this->getDb() );
$this->assertConditions(
[
# expected
"(((actor_user IS NOT NULL AND $notLikeTempUserMatchExpression) AND "
. "(user_editcount >= 10 AND (user_registration IS NULL OR user_registration <= '{$this->getDb()->timestamp( '20201227000000' )}')) AND "
. "(user_editcount < 500 OR user_registration > '{$this->getDb()->timestamp( '20201201000000' )}')"
. "))"
],
[
'userExpLevel' => 'learner'
],
"rc conditions: userExpLevel=learner"
);
}
public function testFilterUserExpLevelUnregisteredOrExperienced() {
Support multiple matchPatterns in temp user autocreate config Why: * There is a need to update the generation and match pattern on WMF wikis to a new format that includes the year and starts with `~`. As such, the 'matchPattern' key needs to be updated. * Removing the old 'matchPattern' from the wgAutoCreateTempUser config currently leaves existing temporary accounts as no longer recongnised as temporary accounts. * Instead, the 'matchPattern' needs to be able to take an array of string patterns so that old patterns can still be used for matching. What: * Update the MainConfigSchama to indicate that 'matchPattern' in the wgAutoCreateTempUser config can be an array of strings. * Add TempUserConfig::getMatchPatterns and deprecate TempUserConfig:: getMatchPattern. This is needed because ::getMatchPattern was typed to only ever return one Pattern, which is no longer the case with this config change. * Update the RealTempUserConfig to support multiple patterns defined in the 'matchPattern' key. The RealTempUserConfig::getMatchPattern method returns the pattern or first pattern if multiple are defined to allow time for existing usages of this deprecated method to be updated. * Update the RealTempUserConfig to rely on other methods instead of checking object property values where possible (e.g. use ::isEnabled instead of checking $this->enabled) to allow easier unit testing. * Update UserSelectQueryBuilder and ChangesListSpecialPage to use TempUserConfig ::getMatchPatterns instead of ::getMatchPattern. * Update mediawiki.util/util.js to be able to parse the 'matchPattern' value when it is an array of strings. * Update maintenance/userOptions.php to use ::getMatchPatterns instead of ::getMatchPattern. * Add and update unit and integration tests for the new code, as well as expanding coverage over existing code that was indirectly affected. Bug: T354619 Change-Id: I3763daefe4dc7c76370bd934fb20452591c9c762
2024-01-10 23:40:27 +00:00
$this->disableAutoCreateTempUser();
ConvertibleTimestamp::setFakeTime( '20201231000000' );
$this->assertConditions(
[
# expected
"(actor_user IS NULL OR "
. "(actor_user IS NOT NULL AND "
. "(user_editcount >= 500 AND (user_registration IS NULL OR user_registration <= '{$this->getDb()->timestamp( '20201201000000' )}'))"
. "))"
],
[
'userExpLevel' => 'unregistered;experienced'
],
"rc conditions: userExpLevel=unregistered;experienced"
);
}
Support multiple matchPatterns in temp user autocreate config Why: * There is a need to update the generation and match pattern on WMF wikis to a new format that includes the year and starts with `~`. As such, the 'matchPattern' key needs to be updated. * Removing the old 'matchPattern' from the wgAutoCreateTempUser config currently leaves existing temporary accounts as no longer recongnised as temporary accounts. * Instead, the 'matchPattern' needs to be able to take an array of string patterns so that old patterns can still be used for matching. What: * Update the MainConfigSchama to indicate that 'matchPattern' in the wgAutoCreateTempUser config can be an array of strings. * Add TempUserConfig::getMatchPatterns and deprecate TempUserConfig:: getMatchPattern. This is needed because ::getMatchPattern was typed to only ever return one Pattern, which is no longer the case with this config change. * Update the RealTempUserConfig to support multiple patterns defined in the 'matchPattern' key. The RealTempUserConfig::getMatchPattern method returns the pattern or first pattern if multiple are defined to allow time for existing usages of this deprecated method to be updated. * Update the RealTempUserConfig to rely on other methods instead of checking object property values where possible (e.g. use ::isEnabled instead of checking $this->enabled) to allow easier unit testing. * Update UserSelectQueryBuilder and ChangesListSpecialPage to use TempUserConfig ::getMatchPatterns instead of ::getMatchPattern. * Update mediawiki.util/util.js to be able to parse the 'matchPattern' value when it is an array of strings. * Update maintenance/userOptions.php to use ::getMatchPatterns instead of ::getMatchPattern. * Add and update unit and integration tests for the new code, as well as expanding coverage over existing code that was indirectly affected. Bug: T354619 Change-Id: I3763daefe4dc7c76370bd934fb20452591c9c762
2024-01-10 23:40:27 +00:00
public function testFilterUserExpLevelUnregisteredOrExperiencedWhenTemporaryAccountsEnabled() {
$this->enableAutoCreateTempUser();
ConvertibleTimestamp::setFakeTime( '20201231000000' );
$notLikeTempUserMatchExpression = $this->getServiceContainer()->getTempUserConfig()
->getMatchCondition( $this->getDb(), 'actor_name', IExpression::NOT_LIKE )
->toSql( $this->getDb() );
$likeTempUserMatchExpression = $this->getServiceContainer()->getTempUserConfig()
->getMatchCondition( $this->getDb(), 'actor_name', IExpression::LIKE )
->toSql( $this->getDb() );
$this->assertConditions(
[
# expected
"((actor_user IS NULL OR $likeTempUserMatchExpression) OR "
. "((actor_user IS NOT NULL AND $notLikeTempUserMatchExpression) AND "
. "(user_editcount >= 500 AND (user_registration IS NULL OR user_registration <= '{$this->getDb()->timestamp( '20201201000000' )}'))"
. "))"
],
[
'userExpLevel' => 'unregistered;experienced'
],
Support multiple matchPatterns in temp user autocreate config Why: * There is a need to update the generation and match pattern on WMF wikis to a new format that includes the year and starts with `~`. As such, the 'matchPattern' key needs to be updated. * Removing the old 'matchPattern' from the wgAutoCreateTempUser config currently leaves existing temporary accounts as no longer recongnised as temporary accounts. * Instead, the 'matchPattern' needs to be able to take an array of string patterns so that old patterns can still be used for matching. What: * Update the MainConfigSchama to indicate that 'matchPattern' in the wgAutoCreateTempUser config can be an array of strings. * Add TempUserConfig::getMatchPatterns and deprecate TempUserConfig:: getMatchPattern. This is needed because ::getMatchPattern was typed to only ever return one Pattern, which is no longer the case with this config change. * Update the RealTempUserConfig to support multiple patterns defined in the 'matchPattern' key. The RealTempUserConfig::getMatchPattern method returns the pattern or first pattern if multiple are defined to allow time for existing usages of this deprecated method to be updated. * Update the RealTempUserConfig to rely on other methods instead of checking object property values where possible (e.g. use ::isEnabled instead of checking $this->enabled) to allow easier unit testing. * Update UserSelectQueryBuilder and ChangesListSpecialPage to use TempUserConfig ::getMatchPatterns instead of ::getMatchPattern. * Update mediawiki.util/util.js to be able to parse the 'matchPattern' value when it is an array of strings. * Update maintenance/userOptions.php to use ::getMatchPatterns instead of ::getMatchPattern. * Add and update unit and integration tests for the new code, as well as expanding coverage over existing code that was indirectly affected. Bug: T354619 Change-Id: I3763daefe4dc7c76370bd934fb20452591c9c762
2024-01-10 23:40:27 +00:00
"rc conditions: userExpLevel=unregistered;experienced"
);
}
Back-end of new RecentChanges page, refactoring Generate old RC, Related changes (it was already displayed and working on 'Related changes' before this change), and Watchlist/etc. and data for new UI from back-end. This moves everything used for defining the old (unstructured) and new (structured) filters into unified objects, ChangesListFilter and ChangesListFilterGroup (and sub-classes). This includes the query logic (see below) and logic for adding CSS attribution classes. This is a breaking change (for subclasses of ChangesListSpecialpage) due to the signature (and name) change of buildMainQueryConds and doMainQuery. An alternative that I don't think is a breaking change would be to put the filter->DB logic in runMainQueryHook, but then it's doing more than just running a hook. This is because it used to only build $conds here, but it's clear from filterOnUserExperienceLevel filters need more than this. I added all the DB parameters from the hook, but this could be debated. I have an checked and fixed the WMF-deployed extensions affected by this. Other than that, there should be full back-compat (including legacy filters not using the new system). * add hidepatrolled/hideunpatrolled to new UI. * Move userExpLevel from RC to ChangesListSpecialPage. Although for now the structured UI only displays on RC anyway, when it displays on watchlist, it seems we'll want userExpLevel there. Change this to make 'all' exclude unregistered users. * Don't have front-end convert none-selected to 'all' on string_options. * Needs the hideanons/hideliu special redirect to be done before this is merged (T151873) Bug: T152754 Bug: T152797 Change-Id: Iec2d82f6a830403d1c948a280efa58992e0cdee7
2017-02-14 07:55:37 +00:00
public function testFilterUserExpLevel() {
$now = time();
$this->overrideConfigValues( [
MainConfigNames::LearnerEdits => 10,
MainConfigNames::LearnerMemberSince => 4,
MainConfigNames::ExperiencedUserEdits => 500,
MainConfigNames::ExperiencedUserMemberSince => 30,
Back-end of new RecentChanges page, refactoring Generate old RC, Related changes (it was already displayed and working on 'Related changes' before this change), and Watchlist/etc. and data for new UI from back-end. This moves everything used for defining the old (unstructured) and new (structured) filters into unified objects, ChangesListFilter and ChangesListFilterGroup (and sub-classes). This includes the query logic (see below) and logic for adding CSS attribution classes. This is a breaking change (for subclasses of ChangesListSpecialpage) due to the signature (and name) change of buildMainQueryConds and doMainQuery. An alternative that I don't think is a breaking change would be to put the filter->DB logic in runMainQueryHook, but then it's doing more than just running a hook. This is because it used to only build $conds here, but it's clear from filterOnUserExperienceLevel filters need more than this. I added all the DB parameters from the hook, but this could be debated. I have an checked and fixed the WMF-deployed extensions affected by this. Other than that, there should be full back-compat (including legacy filters not using the new system). * add hidepatrolled/hideunpatrolled to new UI. * Move userExpLevel from RC to ChangesListSpecialPage. Although for now the structured UI only displays on RC anyway, when it displays on watchlist, it seems we'll want userExpLevel there. Change this to make 'all' exclude unregistered users. * Don't have front-end convert none-selected to 'all' on string_options. * Needs the hideanons/hideliu special redirect to be done before this is merged (T151873) Bug: T152754 Bug: T152797 Change-Id: Iec2d82f6a830403d1c948a280efa58992e0cdee7
2017-02-14 07:55:37 +00:00
] );
$this->createUsers( [
'Newcomer1' => [ 'edits' => 2, 'days' => 2 ],
'Newcomer2' => [ 'edits' => 12, 'days' => 3 ],
'Newcomer3' => [ 'edits' => 8, 'days' => 5 ],
'Learner1' => [ 'edits' => 15, 'days' => 10 ],
'Learner2' => [ 'edits' => 450, 'days' => 20 ],
'Learner3' => [ 'edits' => 460, 'days' => 33 ],
'Learner4' => [ 'edits' => 525, 'days' => 28 ],
'Experienced1' => [ 'edits' => 538, 'days' => 33 ],
], $now );
Back-end of new RecentChanges page, refactoring Generate old RC, Related changes (it was already displayed and working on 'Related changes' before this change), and Watchlist/etc. and data for new UI from back-end. This moves everything used for defining the old (unstructured) and new (structured) filters into unified objects, ChangesListFilter and ChangesListFilterGroup (and sub-classes). This includes the query logic (see below) and logic for adding CSS attribution classes. This is a breaking change (for subclasses of ChangesListSpecialpage) due to the signature (and name) change of buildMainQueryConds and doMainQuery. An alternative that I don't think is a breaking change would be to put the filter->DB logic in runMainQueryHook, but then it's doing more than just running a hook. This is because it used to only build $conds here, but it's clear from filterOnUserExperienceLevel filters need more than this. I added all the DB parameters from the hook, but this could be debated. I have an checked and fixed the WMF-deployed extensions affected by this. Other than that, there should be full back-compat (including legacy filters not using the new system). * add hidepatrolled/hideunpatrolled to new UI. * Move userExpLevel from RC to ChangesListSpecialPage. Although for now the structured UI only displays on RC anyway, when it displays on watchlist, it seems we'll want userExpLevel there. Change this to make 'all' exclude unregistered users. * Don't have front-end convert none-selected to 'all' on string_options. * Needs the hideanons/hideliu special redirect to be done before this is merged (T151873) Bug: T152754 Bug: T152797 Change-Id: Iec2d82f6a830403d1c948a280efa58992e0cdee7
2017-02-14 07:55:37 +00:00
// newcomers only
$this->assertArrayEquals(
[ 'Newcomer1', 'Newcomer2', 'Newcomer3' ],
$this->fetchUsers( [ 'newcomer' ], $now )
Back-end of new RecentChanges page, refactoring Generate old RC, Related changes (it was already displayed and working on 'Related changes' before this change), and Watchlist/etc. and data for new UI from back-end. This moves everything used for defining the old (unstructured) and new (structured) filters into unified objects, ChangesListFilter and ChangesListFilterGroup (and sub-classes). This includes the query logic (see below) and logic for adding CSS attribution classes. This is a breaking change (for subclasses of ChangesListSpecialpage) due to the signature (and name) change of buildMainQueryConds and doMainQuery. An alternative that I don't think is a breaking change would be to put the filter->DB logic in runMainQueryHook, but then it's doing more than just running a hook. This is because it used to only build $conds here, but it's clear from filterOnUserExperienceLevel filters need more than this. I added all the DB parameters from the hook, but this could be debated. I have an checked and fixed the WMF-deployed extensions affected by this. Other than that, there should be full back-compat (including legacy filters not using the new system). * add hidepatrolled/hideunpatrolled to new UI. * Move userExpLevel from RC to ChangesListSpecialPage. Although for now the structured UI only displays on RC anyway, when it displays on watchlist, it seems we'll want userExpLevel there. Change this to make 'all' exclude unregistered users. * Don't have front-end convert none-selected to 'all' on string_options. * Needs the hideanons/hideliu special redirect to be done before this is merged (T151873) Bug: T152754 Bug: T152797 Change-Id: Iec2d82f6a830403d1c948a280efa58992e0cdee7
2017-02-14 07:55:37 +00:00
);
// newcomers and learner
$this->assertArrayEquals(
[
'Newcomer1', 'Newcomer2', 'Newcomer3',
'Learner1', 'Learner2', 'Learner3', 'Learner4',
],
$this->fetchUsers( [ 'newcomer', 'learner' ], $now )
Back-end of new RecentChanges page, refactoring Generate old RC, Related changes (it was already displayed and working on 'Related changes' before this change), and Watchlist/etc. and data for new UI from back-end. This moves everything used for defining the old (unstructured) and new (structured) filters into unified objects, ChangesListFilter and ChangesListFilterGroup (and sub-classes). This includes the query logic (see below) and logic for adding CSS attribution classes. This is a breaking change (for subclasses of ChangesListSpecialpage) due to the signature (and name) change of buildMainQueryConds and doMainQuery. An alternative that I don't think is a breaking change would be to put the filter->DB logic in runMainQueryHook, but then it's doing more than just running a hook. This is because it used to only build $conds here, but it's clear from filterOnUserExperienceLevel filters need more than this. I added all the DB parameters from the hook, but this could be debated. I have an checked and fixed the WMF-deployed extensions affected by this. Other than that, there should be full back-compat (including legacy filters not using the new system). * add hidepatrolled/hideunpatrolled to new UI. * Move userExpLevel from RC to ChangesListSpecialPage. Although for now the structured UI only displays on RC anyway, when it displays on watchlist, it seems we'll want userExpLevel there. Change this to make 'all' exclude unregistered users. * Don't have front-end convert none-selected to 'all' on string_options. * Needs the hideanons/hideliu special redirect to be done before this is merged (T151873) Bug: T152754 Bug: T152797 Change-Id: Iec2d82f6a830403d1c948a280efa58992e0cdee7
2017-02-14 07:55:37 +00:00
);
// newcomers and more learner
$this->assertArrayEquals(
[
'Newcomer1', 'Newcomer2', 'Newcomer3',
'Experienced1',
],
$this->fetchUsers( [ 'newcomer', 'experienced' ], $now )
Back-end of new RecentChanges page, refactoring Generate old RC, Related changes (it was already displayed and working on 'Related changes' before this change), and Watchlist/etc. and data for new UI from back-end. This moves everything used for defining the old (unstructured) and new (structured) filters into unified objects, ChangesListFilter and ChangesListFilterGroup (and sub-classes). This includes the query logic (see below) and logic for adding CSS attribution classes. This is a breaking change (for subclasses of ChangesListSpecialpage) due to the signature (and name) change of buildMainQueryConds and doMainQuery. An alternative that I don't think is a breaking change would be to put the filter->DB logic in runMainQueryHook, but then it's doing more than just running a hook. This is because it used to only build $conds here, but it's clear from filterOnUserExperienceLevel filters need more than this. I added all the DB parameters from the hook, but this could be debated. I have an checked and fixed the WMF-deployed extensions affected by this. Other than that, there should be full back-compat (including legacy filters not using the new system). * add hidepatrolled/hideunpatrolled to new UI. * Move userExpLevel from RC to ChangesListSpecialPage. Although for now the structured UI only displays on RC anyway, when it displays on watchlist, it seems we'll want userExpLevel there. Change this to make 'all' exclude unregistered users. * Don't have front-end convert none-selected to 'all' on string_options. * Needs the hideanons/hideliu special redirect to be done before this is merged (T151873) Bug: T152754 Bug: T152797 Change-Id: Iec2d82f6a830403d1c948a280efa58992e0cdee7
2017-02-14 07:55:37 +00:00
);
// learner only
$this->assertArrayEquals(
[ 'Learner1', 'Learner2', 'Learner3', 'Learner4' ],
$this->fetchUsers( [ 'learner' ], $now )
Back-end of new RecentChanges page, refactoring Generate old RC, Related changes (it was already displayed and working on 'Related changes' before this change), and Watchlist/etc. and data for new UI from back-end. This moves everything used for defining the old (unstructured) and new (structured) filters into unified objects, ChangesListFilter and ChangesListFilterGroup (and sub-classes). This includes the query logic (see below) and logic for adding CSS attribution classes. This is a breaking change (for subclasses of ChangesListSpecialpage) due to the signature (and name) change of buildMainQueryConds and doMainQuery. An alternative that I don't think is a breaking change would be to put the filter->DB logic in runMainQueryHook, but then it's doing more than just running a hook. This is because it used to only build $conds here, but it's clear from filterOnUserExperienceLevel filters need more than this. I added all the DB parameters from the hook, but this could be debated. I have an checked and fixed the WMF-deployed extensions affected by this. Other than that, there should be full back-compat (including legacy filters not using the new system). * add hidepatrolled/hideunpatrolled to new UI. * Move userExpLevel from RC to ChangesListSpecialPage. Although for now the structured UI only displays on RC anyway, when it displays on watchlist, it seems we'll want userExpLevel there. Change this to make 'all' exclude unregistered users. * Don't have front-end convert none-selected to 'all' on string_options. * Needs the hideanons/hideliu special redirect to be done before this is merged (T151873) Bug: T152754 Bug: T152797 Change-Id: Iec2d82f6a830403d1c948a280efa58992e0cdee7
2017-02-14 07:55:37 +00:00
);
// more experienced only
$this->assertArrayEquals(
[ 'Experienced1' ],
$this->fetchUsers( [ 'experienced' ], $now )
Back-end of new RecentChanges page, refactoring Generate old RC, Related changes (it was already displayed and working on 'Related changes' before this change), and Watchlist/etc. and data for new UI from back-end. This moves everything used for defining the old (unstructured) and new (structured) filters into unified objects, ChangesListFilter and ChangesListFilterGroup (and sub-classes). This includes the query logic (see below) and logic for adding CSS attribution classes. This is a breaking change (for subclasses of ChangesListSpecialpage) due to the signature (and name) change of buildMainQueryConds and doMainQuery. An alternative that I don't think is a breaking change would be to put the filter->DB logic in runMainQueryHook, but then it's doing more than just running a hook. This is because it used to only build $conds here, but it's clear from filterOnUserExperienceLevel filters need more than this. I added all the DB parameters from the hook, but this could be debated. I have an checked and fixed the WMF-deployed extensions affected by this. Other than that, there should be full back-compat (including legacy filters not using the new system). * add hidepatrolled/hideunpatrolled to new UI. * Move userExpLevel from RC to ChangesListSpecialPage. Although for now the structured UI only displays on RC anyway, when it displays on watchlist, it seems we'll want userExpLevel there. Change this to make 'all' exclude unregistered users. * Don't have front-end convert none-selected to 'all' on string_options. * Needs the hideanons/hideliu special redirect to be done before this is merged (T151873) Bug: T152754 Bug: T152797 Change-Id: Iec2d82f6a830403d1c948a280efa58992e0cdee7
2017-02-14 07:55:37 +00:00
);
// learner and more experienced
$this->assertArrayEquals(
[
'Learner1', 'Learner2', 'Learner3', 'Learner4',
'Experienced1',
],
$this->fetchUsers( [ 'learner', 'experienced' ], $now )
Back-end of new RecentChanges page, refactoring Generate old RC, Related changes (it was already displayed and working on 'Related changes' before this change), and Watchlist/etc. and data for new UI from back-end. This moves everything used for defining the old (unstructured) and new (structured) filters into unified objects, ChangesListFilter and ChangesListFilterGroup (and sub-classes). This includes the query logic (see below) and logic for adding CSS attribution classes. This is a breaking change (for subclasses of ChangesListSpecialpage) due to the signature (and name) change of buildMainQueryConds and doMainQuery. An alternative that I don't think is a breaking change would be to put the filter->DB logic in runMainQueryHook, but then it's doing more than just running a hook. This is because it used to only build $conds here, but it's clear from filterOnUserExperienceLevel filters need more than this. I added all the DB parameters from the hook, but this could be debated. I have an checked and fixed the WMF-deployed extensions affected by this. Other than that, there should be full back-compat (including legacy filters not using the new system). * add hidepatrolled/hideunpatrolled to new UI. * Move userExpLevel from RC to ChangesListSpecialPage. Although for now the structured UI only displays on RC anyway, when it displays on watchlist, it seems we'll want userExpLevel there. Change this to make 'all' exclude unregistered users. * Don't have front-end convert none-selected to 'all' on string_options. * Needs the hideanons/hideliu special redirect to be done before this is merged (T151873) Bug: T152754 Bug: T152797 Change-Id: Iec2d82f6a830403d1c948a280efa58992e0cdee7
2017-02-14 07:55:37 +00:00
);
}
private function createUsers( array $specs, int $now ) {
$dbw = $this->getDb();
Back-end of new RecentChanges page, refactoring Generate old RC, Related changes (it was already displayed and working on 'Related changes' before this change), and Watchlist/etc. and data for new UI from back-end. This moves everything used for defining the old (unstructured) and new (structured) filters into unified objects, ChangesListFilter and ChangesListFilterGroup (and sub-classes). This includes the query logic (see below) and logic for adding CSS attribution classes. This is a breaking change (for subclasses of ChangesListSpecialpage) due to the signature (and name) change of buildMainQueryConds and doMainQuery. An alternative that I don't think is a breaking change would be to put the filter->DB logic in runMainQueryHook, but then it's doing more than just running a hook. This is because it used to only build $conds here, but it's clear from filterOnUserExperienceLevel filters need more than this. I added all the DB parameters from the hook, but this could be debated. I have an checked and fixed the WMF-deployed extensions affected by this. Other than that, there should be full back-compat (including legacy filters not using the new system). * add hidepatrolled/hideunpatrolled to new UI. * Move userExpLevel from RC to ChangesListSpecialPage. Although for now the structured UI only displays on RC anyway, when it displays on watchlist, it seems we'll want userExpLevel there. Change this to make 'all' exclude unregistered users. * Don't have front-end convert none-selected to 'all' on string_options. * Needs the hideanons/hideliu special redirect to be done before this is merged (T151873) Bug: T152754 Bug: T152797 Change-Id: Iec2d82f6a830403d1c948a280efa58992e0cdee7
2017-02-14 07:55:37 +00:00
foreach ( $specs as $name => $spec ) {
User::createNew(
$name,
[
'editcount' => $spec['edits'],
'registration' => $dbw->timestamp( $this->daysAgo( $spec['days'], $now ) ),
Back-end of new RecentChanges page, refactoring Generate old RC, Related changes (it was already displayed and working on 'Related changes' before this change), and Watchlist/etc. and data for new UI from back-end. This moves everything used for defining the old (unstructured) and new (structured) filters into unified objects, ChangesListFilter and ChangesListFilterGroup (and sub-classes). This includes the query logic (see below) and logic for adding CSS attribution classes. This is a breaking change (for subclasses of ChangesListSpecialpage) due to the signature (and name) change of buildMainQueryConds and doMainQuery. An alternative that I don't think is a breaking change would be to put the filter->DB logic in runMainQueryHook, but then it's doing more than just running a hook. This is because it used to only build $conds here, but it's clear from filterOnUserExperienceLevel filters need more than this. I added all the DB parameters from the hook, but this could be debated. I have an checked and fixed the WMF-deployed extensions affected by this. Other than that, there should be full back-compat (including legacy filters not using the new system). * add hidepatrolled/hideunpatrolled to new UI. * Move userExpLevel from RC to ChangesListSpecialPage. Although for now the structured UI only displays on RC anyway, when it displays on watchlist, it seems we'll want userExpLevel there. Change this to make 'all' exclude unregistered users. * Don't have front-end convert none-selected to 'all' on string_options. * Needs the hideanons/hideliu special redirect to be done before this is merged (T151873) Bug: T152754 Bug: T152797 Change-Id: Iec2d82f6a830403d1c948a280efa58992e0cdee7
2017-02-14 07:55:37 +00:00
'email' => 'ut',
]
);
}
}
private function fetchUsers( array $filters, int $now ): array {
Back-end of new RecentChanges page, refactoring Generate old RC, Related changes (it was already displayed and working on 'Related changes' before this change), and Watchlist/etc. and data for new UI from back-end. This moves everything used for defining the old (unstructured) and new (structured) filters into unified objects, ChangesListFilter and ChangesListFilterGroup (and sub-classes). This includes the query logic (see below) and logic for adding CSS attribution classes. This is a breaking change (for subclasses of ChangesListSpecialpage) due to the signature (and name) change of buildMainQueryConds and doMainQuery. An alternative that I don't think is a breaking change would be to put the filter->DB logic in runMainQueryHook, but then it's doing more than just running a hook. This is because it used to only build $conds here, but it's clear from filterOnUserExperienceLevel filters need more than this. I added all the DB parameters from the hook, but this could be debated. I have an checked and fixed the WMF-deployed extensions affected by this. Other than that, there should be full back-compat (including legacy filters not using the new system). * add hidepatrolled/hideunpatrolled to new UI. * Move userExpLevel from RC to ChangesListSpecialPage. Although for now the structured UI only displays on RC anyway, when it displays on watchlist, it seems we'll want userExpLevel there. Change this to make 'all' exclude unregistered users. * Don't have front-end convert none-selected to 'all' on string_options. * Needs the hideanons/hideliu special redirect to be done before this is merged (T151873) Bug: T152754 Bug: T152797 Change-Id: Iec2d82f6a830403d1c948a280efa58992e0cdee7
2017-02-14 07:55:37 +00:00
$tables = [];
$conds = [];
$fields = [];
$query_options = [];
$join_conds = [];
sort( $filters );
call_user_func_array(
[ $this->changesListSpecialPage, 'filterOnUserExperienceLevel' ],
[
get_class( $this->changesListSpecialPage ),
$this->changesListSpecialPage->getContext(),
$this->changesListSpecialPage->getDB(),
&$tables,
&$fields,
&$conds,
&$query_options,
&$join_conds,
$filters,
$now
Back-end of new RecentChanges page, refactoring Generate old RC, Related changes (it was already displayed and working on 'Related changes' before this change), and Watchlist/etc. and data for new UI from back-end. This moves everything used for defining the old (unstructured) and new (structured) filters into unified objects, ChangesListFilter and ChangesListFilterGroup (and sub-classes). This includes the query logic (see below) and logic for adding CSS attribution classes. This is a breaking change (for subclasses of ChangesListSpecialpage) due to the signature (and name) change of buildMainQueryConds and doMainQuery. An alternative that I don't think is a breaking change would be to put the filter->DB logic in runMainQueryHook, but then it's doing more than just running a hook. This is because it used to only build $conds here, but it's clear from filterOnUserExperienceLevel filters need more than this. I added all the DB parameters from the hook, but this could be debated. I have an checked and fixed the WMF-deployed extensions affected by this. Other than that, there should be full back-compat (including legacy filters not using the new system). * add hidepatrolled/hideunpatrolled to new UI. * Move userExpLevel from RC to ChangesListSpecialPage. Although for now the structured UI only displays on RC anyway, when it displays on watchlist, it seems we'll want userExpLevel there. Change this to make 'all' exclude unregistered users. * Don't have front-end convert none-selected to 'all' on string_options. * Needs the hideanons/hideliu special redirect to be done before this is merged (T151873) Bug: T152754 Bug: T152797 Change-Id: Iec2d82f6a830403d1c948a280efa58992e0cdee7
2017-02-14 07:55:37 +00:00
]
);
// @todo: This is not at all safe or sensible. It just blindly assumes
// nothing in $conds depends on any other tables.
$result = $this->getDb()->newSelectQueryBuilder()
->select( 'user_name' )
->from( 'user' )
->leftJoin( 'actor', null, 'actor_user=user_id' )
->where( $conds )
->andWhere( [ 'user_email' => 'ut' ] )
->fetchResultSet();
Back-end of new RecentChanges page, refactoring Generate old RC, Related changes (it was already displayed and working on 'Related changes' before this change), and Watchlist/etc. and data for new UI from back-end. This moves everything used for defining the old (unstructured) and new (structured) filters into unified objects, ChangesListFilter and ChangesListFilterGroup (and sub-classes). This includes the query logic (see below) and logic for adding CSS attribution classes. This is a breaking change (for subclasses of ChangesListSpecialpage) due to the signature (and name) change of buildMainQueryConds and doMainQuery. An alternative that I don't think is a breaking change would be to put the filter->DB logic in runMainQueryHook, but then it's doing more than just running a hook. This is because it used to only build $conds here, but it's clear from filterOnUserExperienceLevel filters need more than this. I added all the DB parameters from the hook, but this could be debated. I have an checked and fixed the WMF-deployed extensions affected by this. Other than that, there should be full back-compat (including legacy filters not using the new system). * add hidepatrolled/hideunpatrolled to new UI. * Move userExpLevel from RC to ChangesListSpecialPage. Although for now the structured UI only displays on RC anyway, when it displays on watchlist, it seems we'll want userExpLevel there. Change this to make 'all' exclude unregistered users. * Don't have front-end convert none-selected to 'all' on string_options. * Needs the hideanons/hideliu special redirect to be done before this is merged (T151873) Bug: T152754 Bug: T152797 Change-Id: Iec2d82f6a830403d1c948a280efa58992e0cdee7
2017-02-14 07:55:37 +00:00
$usernames = [];
foreach ( $result as $row ) {
$usernames[] = $row->user_name;
}
return $usernames;
}
private function daysAgo( int $days, int $now ): int {
Back-end of new RecentChanges page, refactoring Generate old RC, Related changes (it was already displayed and working on 'Related changes' before this change), and Watchlist/etc. and data for new UI from back-end. This moves everything used for defining the old (unstructured) and new (structured) filters into unified objects, ChangesListFilter and ChangesListFilterGroup (and sub-classes). This includes the query logic (see below) and logic for adding CSS attribution classes. This is a breaking change (for subclasses of ChangesListSpecialpage) due to the signature (and name) change of buildMainQueryConds and doMainQuery. An alternative that I don't think is a breaking change would be to put the filter->DB logic in runMainQueryHook, but then it's doing more than just running a hook. This is because it used to only build $conds here, but it's clear from filterOnUserExperienceLevel filters need more than this. I added all the DB parameters from the hook, but this could be debated. I have an checked and fixed the WMF-deployed extensions affected by this. Other than that, there should be full back-compat (including legacy filters not using the new system). * add hidepatrolled/hideunpatrolled to new UI. * Move userExpLevel from RC to ChangesListSpecialPage. Although for now the structured UI only displays on RC anyway, when it displays on watchlist, it seems we'll want userExpLevel there. Change this to make 'all' exclude unregistered users. * Don't have front-end convert none-selected to 'all' on string_options. * Needs the hideanons/hideliu special redirect to be done before this is merged (T151873) Bug: T152754 Bug: T152797 Change-Id: Iec2d82f6a830403d1c948a280efa58992e0cdee7
2017-02-14 07:55:37 +00:00
$secondsPerDay = 86400;
return $now - $days * $secondsPerDay;
Back-end of new RecentChanges page, refactoring Generate old RC, Related changes (it was already displayed and working on 'Related changes' before this change), and Watchlist/etc. and data for new UI from back-end. This moves everything used for defining the old (unstructured) and new (structured) filters into unified objects, ChangesListFilter and ChangesListFilterGroup (and sub-classes). This includes the query logic (see below) and logic for adding CSS attribution classes. This is a breaking change (for subclasses of ChangesListSpecialpage) due to the signature (and name) change of buildMainQueryConds and doMainQuery. An alternative that I don't think is a breaking change would be to put the filter->DB logic in runMainQueryHook, but then it's doing more than just running a hook. This is because it used to only build $conds here, but it's clear from filterOnUserExperienceLevel filters need more than this. I added all the DB parameters from the hook, but this could be debated. I have an checked and fixed the WMF-deployed extensions affected by this. Other than that, there should be full back-compat (including legacy filters not using the new system). * add hidepatrolled/hideunpatrolled to new UI. * Move userExpLevel from RC to ChangesListSpecialPage. Although for now the structured UI only displays on RC anyway, when it displays on watchlist, it seems we'll want userExpLevel there. Change this to make 'all' exclude unregistered users. * Don't have front-end convert none-selected to 'all' on string_options. * Needs the hideanons/hideliu special redirect to be done before this is merged (T151873) Bug: T152754 Bug: T152797 Change-Id: Iec2d82f6a830403d1c948a280efa58992e0cdee7
2017-02-14 07:55:37 +00:00
}
public function testGetStructuredFilterJsData() {
$this->changesListSpecialPage->filterGroups = [];
Back-end of new RecentChanges page, refactoring Generate old RC, Related changes (it was already displayed and working on 'Related changes' before this change), and Watchlist/etc. and data for new UI from back-end. This moves everything used for defining the old (unstructured) and new (structured) filters into unified objects, ChangesListFilter and ChangesListFilterGroup (and sub-classes). This includes the query logic (see below) and logic for adding CSS attribution classes. This is a breaking change (for subclasses of ChangesListSpecialpage) due to the signature (and name) change of buildMainQueryConds and doMainQuery. An alternative that I don't think is a breaking change would be to put the filter->DB logic in runMainQueryHook, but then it's doing more than just running a hook. This is because it used to only build $conds here, but it's clear from filterOnUserExperienceLevel filters need more than this. I added all the DB parameters from the hook, but this could be debated. I have an checked and fixed the WMF-deployed extensions affected by this. Other than that, there should be full back-compat (including legacy filters not using the new system). * add hidepatrolled/hideunpatrolled to new UI. * Move userExpLevel from RC to ChangesListSpecialPage. Although for now the structured UI only displays on RC anyway, when it displays on watchlist, it seems we'll want userExpLevel there. Change this to make 'all' exclude unregistered users. * Don't have front-end convert none-selected to 'all' on string_options. * Needs the hideanons/hideliu special redirect to be done before this is merged (T151873) Bug: T152754 Bug: T152797 Change-Id: Iec2d82f6a830403d1c948a280efa58992e0cdee7
2017-02-14 07:55:37 +00:00
$definition = [
[
'name' => 'gub-group',
'title' => 'gub-group-title',
'class' => ChangesListBooleanFilterGroup::class,
'filters' => [
[
'name' => 'hidefoo',
'label' => 'foo-label',
'description' => 'foo-description',
'default' => true,
'showHide' => 'showhidefoo',
'priority' => 2,
],
[
'name' => 'hidebar',
'label' => 'bar-label',
'description' => 'bar-description',
'default' => false,
'priority' => 4,
]
],
],
[
'name' => 'des-group',
'title' => 'des-group-title',
'class' => ChangesListStringOptionsFilterGroup::class,
'isFullCoverage' => true,
'filters' => [
[
'name' => 'grault',
'label' => 'grault-label',
'description' => 'grault-description',
],
[
'name' => 'garply',
'label' => 'garply-label',
'description' => 'garply-description',
],
],
'queryCallable' => static function () {
Back-end of new RecentChanges page, refactoring Generate old RC, Related changes (it was already displayed and working on 'Related changes' before this change), and Watchlist/etc. and data for new UI from back-end. This moves everything used for defining the old (unstructured) and new (structured) filters into unified objects, ChangesListFilter and ChangesListFilterGroup (and sub-classes). This includes the query logic (see below) and logic for adding CSS attribution classes. This is a breaking change (for subclasses of ChangesListSpecialpage) due to the signature (and name) change of buildMainQueryConds and doMainQuery. An alternative that I don't think is a breaking change would be to put the filter->DB logic in runMainQueryHook, but then it's doing more than just running a hook. This is because it used to only build $conds here, but it's clear from filterOnUserExperienceLevel filters need more than this. I added all the DB parameters from the hook, but this could be debated. I have an checked and fixed the WMF-deployed extensions affected by this. Other than that, there should be full back-compat (including legacy filters not using the new system). * add hidepatrolled/hideunpatrolled to new UI. * Move userExpLevel from RC to ChangesListSpecialPage. Although for now the structured UI only displays on RC anyway, when it displays on watchlist, it seems we'll want userExpLevel there. Change this to make 'all' exclude unregistered users. * Don't have front-end convert none-selected to 'all' on string_options. * Needs the hideanons/hideliu special redirect to be done before this is merged (T151873) Bug: T152754 Bug: T152797 Change-Id: Iec2d82f6a830403d1c948a280efa58992e0cdee7
2017-02-14 07:55:37 +00:00
},
'default' => ChangesListStringOptionsFilterGroup::NONE,
],
[
'name' => 'unstructured',
'class' => ChangesListBooleanFilterGroup::class,
'filters' => [
[
'name' => 'hidethud',
'showHide' => 'showhidethud',
'default' => true,
],
[
'name' => 'hidemos',
'showHide' => 'showhidemos',
'default' => false,
],
],
],
];
$this->changesListSpecialPage->registerFiltersFromDefinitions( $definition );
$this->assertArrayEquals(
[
// Filters that only display in the unstructured UI are
// are not included, and neither are groups that would
// be empty due to the above.
'groups' => [
[
'name' => 'gub-group',
'title' => 'gub-group-title',
'type' => ChangesListBooleanFilterGroup::TYPE,
'priority' => -1,
'filters' => [
[
'name' => 'hidebar',
'label' => 'bar-label',
'description' => 'bar-description',
'default' => false,
'priority' => 4,
'cssClass' => null,
'conflicts' => [],
'subset' => [],
'defaultHighlightColor' => null
Back-end of new RecentChanges page, refactoring Generate old RC, Related changes (it was already displayed and working on 'Related changes' before this change), and Watchlist/etc. and data for new UI from back-end. This moves everything used for defining the old (unstructured) and new (structured) filters into unified objects, ChangesListFilter and ChangesListFilterGroup (and sub-classes). This includes the query logic (see below) and logic for adding CSS attribution classes. This is a breaking change (for subclasses of ChangesListSpecialpage) due to the signature (and name) change of buildMainQueryConds and doMainQuery. An alternative that I don't think is a breaking change would be to put the filter->DB logic in runMainQueryHook, but then it's doing more than just running a hook. This is because it used to only build $conds here, but it's clear from filterOnUserExperienceLevel filters need more than this. I added all the DB parameters from the hook, but this could be debated. I have an checked and fixed the WMF-deployed extensions affected by this. Other than that, there should be full back-compat (including legacy filters not using the new system). * add hidepatrolled/hideunpatrolled to new UI. * Move userExpLevel from RC to ChangesListSpecialPage. Although for now the structured UI only displays on RC anyway, when it displays on watchlist, it seems we'll want userExpLevel there. Change this to make 'all' exclude unregistered users. * Don't have front-end convert none-selected to 'all' on string_options. * Needs the hideanons/hideliu special redirect to be done before this is merged (T151873) Bug: T152754 Bug: T152797 Change-Id: Iec2d82f6a830403d1c948a280efa58992e0cdee7
2017-02-14 07:55:37 +00:00
],
[
'name' => 'hidefoo',
'label' => 'foo-label',
'description' => 'foo-description',
'default' => true,
'priority' => 2,
'cssClass' => null,
'conflicts' => [],
'subset' => [],
'defaultHighlightColor' => null
Back-end of new RecentChanges page, refactoring Generate old RC, Related changes (it was already displayed and working on 'Related changes' before this change), and Watchlist/etc. and data for new UI from back-end. This moves everything used for defining the old (unstructured) and new (structured) filters into unified objects, ChangesListFilter and ChangesListFilterGroup (and sub-classes). This includes the query logic (see below) and logic for adding CSS attribution classes. This is a breaking change (for subclasses of ChangesListSpecialpage) due to the signature (and name) change of buildMainQueryConds and doMainQuery. An alternative that I don't think is a breaking change would be to put the filter->DB logic in runMainQueryHook, but then it's doing more than just running a hook. This is because it used to only build $conds here, but it's clear from filterOnUserExperienceLevel filters need more than this. I added all the DB parameters from the hook, but this could be debated. I have an checked and fixed the WMF-deployed extensions affected by this. Other than that, there should be full back-compat (including legacy filters not using the new system). * add hidepatrolled/hideunpatrolled to new UI. * Move userExpLevel from RC to ChangesListSpecialPage. Although for now the structured UI only displays on RC anyway, when it displays on watchlist, it seems we'll want userExpLevel there. Change this to make 'all' exclude unregistered users. * Don't have front-end convert none-selected to 'all' on string_options. * Needs the hideanons/hideliu special redirect to be done before this is merged (T151873) Bug: T152754 Bug: T152797 Change-Id: Iec2d82f6a830403d1c948a280efa58992e0cdee7
2017-02-14 07:55:37 +00:00
],
],
'fullCoverage' => true,
'conflicts' => [],
],
[
'name' => 'des-group',
'title' => 'des-group-title',
'type' => ChangesListStringOptionsFilterGroup::TYPE,
'priority' => -2,
'fullCoverage' => true,
'filters' => [
[
'name' => 'grault',
'label' => 'grault-label',
'description' => 'grault-description',
'cssClass' => null,
'priority' => -2,
'conflicts' => [],
'subset' => [],
'defaultHighlightColor' => null
Back-end of new RecentChanges page, refactoring Generate old RC, Related changes (it was already displayed and working on 'Related changes' before this change), and Watchlist/etc. and data for new UI from back-end. This moves everything used for defining the old (unstructured) and new (structured) filters into unified objects, ChangesListFilter and ChangesListFilterGroup (and sub-classes). This includes the query logic (see below) and logic for adding CSS attribution classes. This is a breaking change (for subclasses of ChangesListSpecialpage) due to the signature (and name) change of buildMainQueryConds and doMainQuery. An alternative that I don't think is a breaking change would be to put the filter->DB logic in runMainQueryHook, but then it's doing more than just running a hook. This is because it used to only build $conds here, but it's clear from filterOnUserExperienceLevel filters need more than this. I added all the DB parameters from the hook, but this could be debated. I have an checked and fixed the WMF-deployed extensions affected by this. Other than that, there should be full back-compat (including legacy filters not using the new system). * add hidepatrolled/hideunpatrolled to new UI. * Move userExpLevel from RC to ChangesListSpecialPage. Although for now the structured UI only displays on RC anyway, when it displays on watchlist, it seems we'll want userExpLevel there. Change this to make 'all' exclude unregistered users. * Don't have front-end convert none-selected to 'all' on string_options. * Needs the hideanons/hideliu special redirect to be done before this is merged (T151873) Bug: T152754 Bug: T152797 Change-Id: Iec2d82f6a830403d1c948a280efa58992e0cdee7
2017-02-14 07:55:37 +00:00
],
[
'name' => 'garply',
'label' => 'garply-label',
'description' => 'garply-description',
'cssClass' => null,
'priority' => -3,
'conflicts' => [],
'subset' => [],
'defaultHighlightColor' => null
Back-end of new RecentChanges page, refactoring Generate old RC, Related changes (it was already displayed and working on 'Related changes' before this change), and Watchlist/etc. and data for new UI from back-end. This moves everything used for defining the old (unstructured) and new (structured) filters into unified objects, ChangesListFilter and ChangesListFilterGroup (and sub-classes). This includes the query logic (see below) and logic for adding CSS attribution classes. This is a breaking change (for subclasses of ChangesListSpecialpage) due to the signature (and name) change of buildMainQueryConds and doMainQuery. An alternative that I don't think is a breaking change would be to put the filter->DB logic in runMainQueryHook, but then it's doing more than just running a hook. This is because it used to only build $conds here, but it's clear from filterOnUserExperienceLevel filters need more than this. I added all the DB parameters from the hook, but this could be debated. I have an checked and fixed the WMF-deployed extensions affected by this. Other than that, there should be full back-compat (including legacy filters not using the new system). * add hidepatrolled/hideunpatrolled to new UI. * Move userExpLevel from RC to ChangesListSpecialPage. Although for now the structured UI only displays on RC anyway, when it displays on watchlist, it seems we'll want userExpLevel there. Change this to make 'all' exclude unregistered users. * Don't have front-end convert none-selected to 'all' on string_options. * Needs the hideanons/hideliu special redirect to be done before this is merged (T151873) Bug: T152754 Bug: T152797 Change-Id: Iec2d82f6a830403d1c948a280efa58992e0cdee7
2017-02-14 07:55:37 +00:00
],
],
'conflicts' => [],
'separator' => ';',
'default' => ChangesListStringOptionsFilterGroup::NONE,
],
],
'messageKeys' => [
'gub-group-title',
'bar-label',
'bar-description',
'foo-label',
'foo-description',
'des-group-title',
'grault-label',
'grault-description',
'garply-label',
'garply-description',
],
],
$this->changesListSpecialPage->getStructuredFilterJsData(),
/** ordered= */ false,
/** named= */ true
);
}
public function provideParseParameters() {
return [
[ 'hidebots', [ 'hidebots' => true ] ],
[ 'bots', [ 'hidebots' => false ] ],
[ 'hideminor', [ 'hideminor' => true ] ],
[ 'minor', [ 'hideminor' => false ] ],
[ 'hidemajor', [ 'hidemajor' => true ] ],
[ 'hideliu', [ 'hideliu' => true ] ],
[ 'hidepatrolled', [ 'hidepatrolled' => true ] ],
[ 'hideunpatrolled', [ 'hideunpatrolled' => true ] ],
[ 'hideanons', [ 'hideanons' => true ] ],
[ 'hidemyself', [ 'hidemyself' => true ] ],
[ 'hidebyothers', [ 'hidebyothers' => true ] ],
[ 'hidehumans', [ 'hidehumans' => true ] ],
[ 'hidepageedits', [ 'hidepageedits' => true ] ],
[ 'pagedits', [ 'hidepageedits' => false ] ],
[ 'hidenewpages', [ 'hidenewpages' => true ] ],
[ 'hidecategorization', [ 'hidecategorization' => true ] ],
[ 'hidelog', [ 'hidelog' => true ] ],
[
'userExpLevel=learner;experienced',
[
'userExpLevel' => 'learner;experienced'
],
],
// A few random combos
[
'bots,hideliu,hidemyself',
[
'hidebots' => false,
'hideliu' => true,
'hidemyself' => true,
],
],
[
'minor,hideanons,categorization',
[
'hideminor' => false,
'hideanons' => true,
'hidecategorization' => false,
]
],
[
'hidehumans,bots,hidecategorization',
[
'hidehumans' => true,
'hidebots' => false,
'hidecategorization' => true,
],
],
[
'hidemyself,userExpLevel=newcomer;learner,hideminor',
[
'hidemyself' => true,
'hideminor' => true,
'userExpLevel' => 'newcomer;learner',
],
],
];
}
public static function provideGetFilterConflicts() {
return [
[
"parameters" => [],
"expectedConflicts" => false,
],
[
"parameters" => [
"hideliu" => true,
"userExpLevel" => "newcomer",
],
"expectedConflicts" => false,
],
[
"parameters" => [
"hideanons" => true,
"userExpLevel" => "learner",
],
"expectedConflicts" => false,
],
[
"parameters" => [
"hidemajor" => true,
"hidenewpages" => true,
"hidepageedits" => true,
"hidecategorization" => false,
"hidelog" => true,
"hideWikidata" => true,
],
"expectedConflicts" => true,
],
[
"parameters" => [
"hidemajor" => true,
"hidenewpages" => false,
"hidepageedits" => true,
"hidecategorization" => false,
"hidelog" => false,
"hideWikidata" => true,
],
"expectedConflicts" => true,
],
[
"parameters" => [
"hidemajor" => true,
"hidenewpages" => false,
"hidepageedits" => false,
"hidecategorization" => true,
"hidelog" => true,
"hideWikidata" => true,
],
"expectedConflicts" => false,
],
[
"parameters" => [
"hideminor" => true,
"hidenewpages" => true,
"hidepageedits" => true,
"hidecategorization" => false,
"hidelog" => true,
"hideWikidata" => true,
],
"expectedConflicts" => false,
],
];
}
/**
* @dataProvider provideGetFilterConflicts
*/
public function testGetFilterConflicts( $parameters, $expectedConflicts ) {
$context = new RequestContext;
$context->setRequest( new FauxRequest( $parameters ) );
$this->changesListSpecialPage->setContext( $context );
$this->assertEquals(
$expectedConflicts,
$this->changesListSpecialPage->areFiltersInConflict()
);
}
public function validateOptionsProvider() {
return [
[
[ 'hideanons' => 1, 'hideliu' => 1, 'hidebots' => 1 ],
true,
[ 'userExpLevel' => 'unregistered', 'hidebots' => 1, ],
true,
],
[
[ 'hideanons' => 1, 'hideliu' => 1, 'hidebots' => 0 ],
true,
[ 'hidebots' => 0, 'hidehumans' => 1 ],
true,
],
[
[ 'hideanons' => 1 ],
true,
[ 'userExpLevel' => 'registered' ],
true,
],
[
[ 'hideliu' => 1 ],
true,
[ 'userExpLevel' => 'unregistered' ],
true,
],
[
[ 'hideanons' => 1, 'hidebots' => 1 ],
true,
[ 'userExpLevel' => 'registered', 'hidebots' => 1 ],
true,
],
[
[ 'hideliu' => 1, 'hidebots' => 0 ],
true,
[ 'userExpLevel' => 'unregistered', 'hidebots' => 0 ],
true,
],
[
[ 'hidemyself' => 1, 'hidebyothers' => 1 ],
true,
[],
true,
],
[
[ 'hidebots' => 1, 'hidehumans' => 1 ],
true,
[],
true,
],
[
[ 'hidepatrolled' => 1, 'hideunpatrolled' => 1 ],
true,
[],
true,
],
[
[ 'hideminor' => 1, 'hidemajor' => 1 ],
true,
[],
true,
],
[
// changeType
[ 'hidepageedits' => 1, 'hidenewpages' => 1, 'hidecategorization' => 1, 'hidelog' => 1, 'hidenewuserlog' => 1 ],
true,
[],
true,
],
];
}
Back-end of new RecentChanges page, refactoring Generate old RC, Related changes (it was already displayed and working on 'Related changes' before this change), and Watchlist/etc. and data for new UI from back-end. This moves everything used for defining the old (unstructured) and new (structured) filters into unified objects, ChangesListFilter and ChangesListFilterGroup (and sub-classes). This includes the query logic (see below) and logic for adding CSS attribution classes. This is a breaking change (for subclasses of ChangesListSpecialpage) due to the signature (and name) change of buildMainQueryConds and doMainQuery. An alternative that I don't think is a breaking change would be to put the filter->DB logic in runMainQueryHook, but then it's doing more than just running a hook. This is because it used to only build $conds here, but it's clear from filterOnUserExperienceLevel filters need more than this. I added all the DB parameters from the hook, but this could be debated. I have an checked and fixed the WMF-deployed extensions affected by this. Other than that, there should be full back-compat (including legacy filters not using the new system). * add hidepatrolled/hideunpatrolled to new UI. * Move userExpLevel from RC to ChangesListSpecialPage. Although for now the structured UI only displays on RC anyway, when it displays on watchlist, it seems we'll want userExpLevel there. Change this to make 'all' exclude unregistered users. * Don't have front-end convert none-selected to 'all' on string_options. * Needs the hideanons/hideliu special redirect to be done before this is merged (T151873) Bug: T152754 Bug: T152797 Change-Id: Iec2d82f6a830403d1c948a280efa58992e0cdee7
2017-02-14 07:55:37 +00:00
}