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
|
2017-04-19 19:37:35 +00:00
|
|
|
|
|
|
|
|
|
|
use Wikimedia\TestingAccessWrapper;
|
|
|
|
|
|
|
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 ChangesListSpecialPage
|
|
|
|
|
|
*/
|
|
|
|
|
|
class ChangesListSpecialPageTest extends AbstractChangesListSpecialPageTestCase {
|
|
|
|
|
|
protected function getPage() {
|
2016-12-06 15:25:35 +00:00
|
|
|
|
$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',
|
|
|
|
|
|
''
|
|
|
|
|
|
]
|
|
|
|
|
|
)
|
2016-12-06 15:25:35 +00:00
|
|
|
|
->setMethods( [ '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
|
|
|
|
);
|
2016-12-06 15:25:35 +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
|
|
|
|
}
|
|
|
|
|
|
|
2017-07-14 12:07:41 +00:00
|
|
|
|
private function buildQuery(
|
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
|
|
|
|
$requestOptions = null,
|
|
|
|
|
|
$user = null
|
|
|
|
|
|
) {
|
|
|
|
|
|
$context = new RequestContext;
|
|
|
|
|
|
$context->setRequest( new FauxRequest( $requestOptions ) );
|
|
|
|
|
|
if ( $user ) {
|
|
|
|
|
|
$context->setUser( $user );
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
$this->changesListSpecialPage->setContext( $context );
|
2016-12-06 15:25:35 +00:00
|
|
|
|
$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
|
|
|
|
|
|
# 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,
|
|
|
|
|
|
'ChangesListSpecialPageTest::filterOutRcTimestampCondition'
|
|
|
|
|
|
);
|
|
|
|
|
|
|
2017-07-14 12:07:41 +00:00
|
|
|
|
return $queryConditions;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/** helper to test SpecialRecentchanges::buildQuery() */
|
|
|
|
|
|
private function assertConditions(
|
|
|
|
|
|
$expected,
|
|
|
|
|
|
$requestOptions = null,
|
|
|
|
|
|
$message = '',
|
|
|
|
|
|
$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(
|
|
|
|
|
|
self::normalizeCondition( $expected ),
|
|
|
|
|
|
self::normalizeCondition( $queryConditions ),
|
|
|
|
|
|
$message
|
|
|
|
|
|
);
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
private static function normalizeCondition( $conds ) {
|
|
|
|
|
|
$normalized = array_map(
|
|
|
|
|
|
function ( $k, $v ) {
|
|
|
|
|
|
return is_numeric( $k ) ? $v : "$k = $v";
|
|
|
|
|
|
},
|
|
|
|
|
|
array_keys( $conds ),
|
|
|
|
|
|
$conds
|
|
|
|
|
|
);
|
|
|
|
|
|
sort( $normalized );
|
|
|
|
|
|
return $normalized;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/** return false if condition begin with 'rc_timestamp ' */
|
|
|
|
|
|
private static function filterOutRcTimestampCondition( $var ) {
|
|
|
|
|
|
return ( false === strpos( $var, 'rc_timestamp ' ) );
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
public function testRcNsFilter() {
|
|
|
|
|
|
$this->assertConditions(
|
|
|
|
|
|
[ # expected
|
|
|
|
|
|
"rc_namespace = '0'",
|
|
|
|
|
|
],
|
|
|
|
|
|
[
|
|
|
|
|
|
'namespace' => NS_MAIN,
|
|
|
|
|
|
],
|
2017-05-02 17:47:17 +00:00
|
|
|
|
"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'",
|
|
|
|
|
|
],
|
|
|
|
|
|
[
|
|
|
|
|
|
'namespace' => NS_MAIN,
|
|
|
|
|
|
'invert' => 1,
|
|
|
|
|
|
],
|
|
|
|
|
|
"rc conditions with namespace inverted"
|
|
|
|
|
|
);
|
|
|
|
|
|
}
|
|
|
|
|
|
|
2017-05-02 17:47:17 +00:00
|
|
|
|
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
|
2017-05-02 17:47:17 +00:00
|
|
|
|
"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
|
|
|
|
],
|
|
|
|
|
|
[
|
2017-05-08 05:06:12 +00:00
|
|
|
|
'namespace' => '1;2;3',
|
2017-05-02 17:47:17 +00:00
|
|
|
|
],
|
|
|
|
|
|
"rc conditions with multiple namespaces"
|
|
|
|
|
|
);
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
public function testRcNsFilterMultipleAssociated() {
|
|
|
|
|
|
$this->assertConditions(
|
|
|
|
|
|
[ # expected
|
|
|
|
|
|
"rc_namespace IN ('0','1','4','5','6','7')",
|
|
|
|
|
|
],
|
|
|
|
|
|
[
|
2017-05-08 05:06:12 +00:00
|
|
|
|
'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,
|
|
|
|
|
|
],
|
2017-05-02 17:47:17 +00:00
|
|
|
|
"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
|
|
|
|
);
|
|
|
|
|
|
}
|
|
|
|
|
|
|
2017-05-02 17:47:17 +00:00
|
|
|
|
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
|
2017-05-02 17:47:17 +00:00
|
|
|
|
"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
|
|
|
|
],
|
|
|
|
|
|
[
|
2017-05-08 05:06:12 +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,
|
2017-05-02 17:47:17 +00:00
|
|
|
|
'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
|
|
|
|
],
|
2017-05-02 17:47:17 +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
|
|
|
|
);
|
|
|
|
|
|
}
|
|
|
|
|
|
|
2017-05-02 17:47:17 +00:00
|
|
|
|
public function testRcNsFilterMultipleInvert() {
|
|
|
|
|
|
$this->assertConditions(
|
|
|
|
|
|
[ # expected
|
|
|
|
|
|
"rc_namespace NOT IN ('1','2','3')",
|
|
|
|
|
|
],
|
|
|
|
|
|
[
|
2017-05-08 05:06:12 +00:00
|
|
|
|
'namespace' => '1;2;3',
|
2017-05-02 17:47:17 +00:00
|
|
|
|
'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 testRcHidemyselfFilter() {
|
|
|
|
|
|
$user = $this->getTestUser()->getUser();
|
|
|
|
|
|
$this->assertConditions(
|
|
|
|
|
|
[ # expected
|
2017-03-27 21:06:01 +00:00
|
|
|
|
"rc_user_text != '{$user->getName()}'",
|
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
|
|
|
|
],
|
|
|
|
|
|
[
|
|
|
|
|
|
'hidemyself' => 1,
|
|
|
|
|
|
],
|
|
|
|
|
|
"rc conditions: hidemyself=1 (logged in)",
|
|
|
|
|
|
$user
|
|
|
|
|
|
);
|
|
|
|
|
|
|
|
|
|
|
|
$user = User::newFromName( '10.11.12.13', false );
|
|
|
|
|
|
$this->assertConditions(
|
|
|
|
|
|
[ # expected
|
|
|
|
|
|
"rc_user_text != '10.11.12.13'",
|
|
|
|
|
|
],
|
|
|
|
|
|
[
|
|
|
|
|
|
'hidemyself' => 1,
|
|
|
|
|
|
],
|
|
|
|
|
|
"rc conditions: hidemyself=1 (anon)",
|
|
|
|
|
|
$user
|
|
|
|
|
|
);
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
public function testRcHidebyothersFilter() {
|
|
|
|
|
|
$user = $this->getTestUser()->getUser();
|
|
|
|
|
|
$this->assertConditions(
|
|
|
|
|
|
[ # expected
|
2017-03-27 21:06:01 +00:00
|
|
|
|
"rc_user_text = '{$user->getName()}'",
|
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
|
|
|
|
],
|
|
|
|
|
|
[
|
|
|
|
|
|
'hidebyothers' => 1,
|
|
|
|
|
|
],
|
|
|
|
|
|
"rc conditions: hidebyothers=1 (logged in)",
|
|
|
|
|
|
$user
|
|
|
|
|
|
);
|
|
|
|
|
|
|
|
|
|
|
|
$user = User::newFromName( '10.11.12.13', false );
|
|
|
|
|
|
$this->assertConditions(
|
|
|
|
|
|
[ # expected
|
|
|
|
|
|
"rc_user_text = '10.11.12.13'",
|
|
|
|
|
|
],
|
|
|
|
|
|
[
|
|
|
|
|
|
'hidebyothers' => 1,
|
|
|
|
|
|
],
|
|
|
|
|
|
"rc conditions: hidebyothers=1 (anon)",
|
|
|
|
|
|
$user
|
|
|
|
|
|
);
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
public function testRcHidepageedits() {
|
|
|
|
|
|
$this->assertConditions(
|
|
|
|
|
|
[ # expected
|
|
|
|
|
|
"rc_type != '0'",
|
|
|
|
|
|
],
|
|
|
|
|
|
[
|
|
|
|
|
|
'hidepageedits' => 1,
|
|
|
|
|
|
],
|
|
|
|
|
|
"rc conditions: hidepageedits=1"
|
|
|
|
|
|
);
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
public function testRcHidenewpages() {
|
|
|
|
|
|
$this->assertConditions(
|
|
|
|
|
|
[ # expected
|
|
|
|
|
|
"rc_type != '1'",
|
|
|
|
|
|
],
|
|
|
|
|
|
[
|
|
|
|
|
|
'hidenewpages' => 1,
|
|
|
|
|
|
],
|
|
|
|
|
|
"rc conditions: hidenewpages=1"
|
|
|
|
|
|
);
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
public function testRcHidelog() {
|
|
|
|
|
|
$this->assertConditions(
|
|
|
|
|
|
[ # expected
|
|
|
|
|
|
"rc_type != '3'",
|
|
|
|
|
|
],
|
|
|
|
|
|
[
|
|
|
|
|
|
'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() {
|
2017-09-20 18:41:59 +00:00
|
|
|
|
$this->setMwGlobals( 'wgUseRCPatrol', 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() {
|
2017-09-20 18:41:59 +00:00
|
|
|
|
$this->setMwGlobals( 'wgUseRCPatrol', 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
|
|
|
|
|
|
);
|
|
|
|
|
|
}
|
|
|
|
|
|
public function testRcHidepatrolledFilter() {
|
|
|
|
|
|
$user = $this->getTestSysop()->getUser();
|
|
|
|
|
|
$this->assertConditions(
|
|
|
|
|
|
[ # expected
|
|
|
|
|
|
"rc_patrolled = 0",
|
|
|
|
|
|
],
|
|
|
|
|
|
[
|
|
|
|
|
|
'hidepatrolled' => 1,
|
|
|
|
|
|
],
|
|
|
|
|
|
"rc conditions: hidepatrolled=1",
|
|
|
|
|
|
$user
|
|
|
|
|
|
);
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
public function testRcHideunpatrolledFilter() {
|
|
|
|
|
|
$user = $this->getTestSysop()->getUser();
|
|
|
|
|
|
$this->assertConditions(
|
|
|
|
|
|
[ # expected
|
|
|
|
|
|
"rc_patrolled = 1",
|
|
|
|
|
|
],
|
|
|
|
|
|
[
|
|
|
|
|
|
'hideunpatrolled' => 1,
|
|
|
|
|
|
],
|
|
|
|
|
|
"rc conditions: hideunpatrolled=1",
|
|
|
|
|
|
$user
|
|
|
|
|
|
);
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
public function testRcHideminorFilter() {
|
|
|
|
|
|
$this->assertConditions(
|
|
|
|
|
|
[ # expected
|
|
|
|
|
|
"rc_minor = 0",
|
|
|
|
|
|
],
|
|
|
|
|
|
[
|
|
|
|
|
|
'hideminor' => 1,
|
|
|
|
|
|
],
|
|
|
|
|
|
"rc conditions: hideminor=1"
|
|
|
|
|
|
);
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
public function testRcHidemajorFilter() {
|
|
|
|
|
|
$this->assertConditions(
|
|
|
|
|
|
[ # expected
|
|
|
|
|
|
"rc_minor = 1",
|
|
|
|
|
|
],
|
|
|
|
|
|
[
|
|
|
|
|
|
'hidemajor' => 1,
|
|
|
|
|
|
],
|
|
|
|
|
|
"rc conditions: hidemajor=1"
|
|
|
|
|
|
);
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
public function testHideCategorization() {
|
|
|
|
|
|
$this->assertConditions(
|
|
|
|
|
|
[
|
|
|
|
|
|
# expected
|
|
|
|
|
|
"rc_type != '6'"
|
|
|
|
|
|
],
|
|
|
|
|
|
[
|
|
|
|
|
|
'hidecategorization' => 1
|
|
|
|
|
|
],
|
|
|
|
|
|
"rc conditions: hidecategorization=1"
|
|
|
|
|
|
);
|
|
|
|
|
|
}
|
|
|
|
|
|
|
2017-07-14 12:07:41 +00:00
|
|
|
|
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() {
|
|
|
|
|
|
$this->assertConditions(
|
|
|
|
|
|
[
|
|
|
|
|
|
# expected
|
|
|
|
|
|
'rc_user != 0',
|
|
|
|
|
|
],
|
|
|
|
|
|
[
|
|
|
|
|
|
'userExpLevel' => 'newcomer;learner;experienced',
|
|
|
|
|
|
],
|
|
|
|
|
|
"rc conditions: userExpLevel=newcomer;learner;experienced"
|
|
|
|
|
|
);
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
public function testFilterUserExpLevelRegistrered() {
|
|
|
|
|
|
$this->assertConditions(
|
|
|
|
|
|
[
|
|
|
|
|
|
# expected
|
|
|
|
|
|
'rc_user != 0',
|
|
|
|
|
|
],
|
|
|
|
|
|
[
|
|
|
|
|
|
'userExpLevel' => 'registered',
|
|
|
|
|
|
],
|
|
|
|
|
|
"rc conditions: userExpLevel=registered"
|
|
|
|
|
|
);
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
public function testFilterUserExpLevelUnregistrered() {
|
|
|
|
|
|
$this->assertConditions(
|
|
|
|
|
|
[
|
|
|
|
|
|
# expected
|
|
|
|
|
|
'rc_user' => 0,
|
|
|
|
|
|
],
|
|
|
|
|
|
[
|
|
|
|
|
|
'userExpLevel' => 'unregistered',
|
|
|
|
|
|
],
|
|
|
|
|
|
"rc conditions: userExpLevel=unregistered"
|
|
|
|
|
|
);
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
public function testFilterUserExpLevelRegistreredOrLearner() {
|
|
|
|
|
|
$this->assertConditions(
|
|
|
|
|
|
[
|
|
|
|
|
|
# expected
|
|
|
|
|
|
'rc_user != 0',
|
|
|
|
|
|
],
|
|
|
|
|
|
[
|
|
|
|
|
|
'userExpLevel' => 'registered;learner',
|
|
|
|
|
|
],
|
|
|
|
|
|
"rc conditions: userExpLevel=registered;learner"
|
|
|
|
|
|
);
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
public function testFilterUserExpLevelUnregistreredOrExperienced() {
|
|
|
|
|
|
$conds = $this->buildQuery( [ 'userExpLevel' => 'unregistered;experienced' ] );
|
|
|
|
|
|
|
|
|
|
|
|
$this->assertRegExp(
|
2017-07-29 00:36:25 +00:00
|
|
|
|
'/\(rc_user = 0\) OR \(\(user_editcount >= 500\) AND \(user_registration <= \'[^\']+\'\)\)/',
|
2017-07-14 12:07:41 +00:00
|
|
|
|
reset( $conds ),
|
|
|
|
|
|
"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() {
|
2017-04-24 12:54:10 +00:00
|
|
|
|
$now = time();
|
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->setMwGlobals( [
|
|
|
|
|
|
'wgLearnerEdits' => 10,
|
|
|
|
|
|
'wgLearnerMemberSince' => 4,
|
|
|
|
|
|
'wgExperiencedUserEdits' => 500,
|
|
|
|
|
|
'wgExperiencedUserMemberSince' => 30,
|
|
|
|
|
|
] );
|
|
|
|
|
|
|
|
|
|
|
|
$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 ],
|
2017-04-24 12:54:10 +00:00
|
|
|
|
], $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' ],
|
2017-04-24 12:54:10 +00:00
|
|
|
|
$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',
|
|
|
|
|
|
],
|
2017-04-24 12:54:10 +00:00
|
|
|
|
$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',
|
|
|
|
|
|
],
|
2017-04-24 12:54:10 +00:00
|
|
|
|
$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' ],
|
2017-04-24 12:54:10 +00:00
|
|
|
|
$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' ],
|
2017-04-24 12:54:10 +00:00
|
|
|
|
$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',
|
|
|
|
|
|
],
|
2017-04-24 12:54:10 +00:00
|
|
|
|
$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
|
|
|
|
'Learner and more experienced'
|
|
|
|
|
|
);
|
|
|
|
|
|
}
|
|
|
|
|
|
|
2017-04-24 12:54:10 +00:00
|
|
|
|
private function createUsers( $specs, $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
|
|
|
|
$dbw = wfGetDB( DB_MASTER );
|
|
|
|
|
|
foreach ( $specs as $name => $spec ) {
|
|
|
|
|
|
User::createNew(
|
|
|
|
|
|
$name,
|
|
|
|
|
|
[
|
|
|
|
|
|
'editcount' => $spec['edits'],
|
2017-04-24 12:54:10 +00:00
|
|
|
|
'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',
|
|
|
|
|
|
]
|
|
|
|
|
|
);
|
|
|
|
|
|
}
|
|
|
|
|
|
}
|
|
|
|
|
|
|
2017-04-24 12:54:10 +00:00
|
|
|
|
private function fetchUsers( $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
|
|
|
|
$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,
|
2017-04-24 12:54:10 +00:00
|
|
|
|
$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
|
|
|
|
]
|
|
|
|
|
|
);
|
|
|
|
|
|
|
|
|
|
|
|
$result = wfGetDB( DB_MASTER )->select(
|
2017-04-21 16:15:40 +00:00
|
|
|
|
$tables,
|
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_name',
|
|
|
|
|
|
array_filter( $conds ) + [ 'user_email' => 'ut' ]
|
|
|
|
|
|
);
|
|
|
|
|
|
|
|
|
|
|
|
$usernames = [];
|
|
|
|
|
|
foreach ( $result as $row ) {
|
|
|
|
|
|
$usernames[] = $row->user_name;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
return $usernames;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
2017-04-24 12:54:10 +00:00
|
|
|
|
private function daysAgo( $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
|
|
|
|
$secondsPerDay = 86400;
|
2017-04-24 12:54:10 +00:00
|
|
|
|
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 testGetFilterGroupDefinitionFromLegacyCustomFilters() {
|
|
|
|
|
|
$customFilters = [
|
|
|
|
|
|
'hidefoo' => [
|
|
|
|
|
|
'msg' => 'showhidefoo',
|
|
|
|
|
|
'default' => true,
|
|
|
|
|
|
],
|
|
|
|
|
|
|
|
|
|
|
|
'hidebar' => [
|
|
|
|
|
|
'msg' => 'showhidebar',
|
|
|
|
|
|
'default' => false,
|
|
|
|
|
|
],
|
|
|
|
|
|
];
|
|
|
|
|
|
|
|
|
|
|
|
$this->assertEquals(
|
|
|
|
|
|
[
|
|
|
|
|
|
'name' => 'unstructured',
|
|
|
|
|
|
'class' => ChangesListBooleanFilterGroup::class,
|
|
|
|
|
|
'priority' => -1,
|
|
|
|
|
|
'filters' => [
|
|
|
|
|
|
[
|
|
|
|
|
|
'name' => 'hidefoo',
|
|
|
|
|
|
'showHide' => 'showhidefoo',
|
|
|
|
|
|
'default' => true,
|
|
|
|
|
|
],
|
|
|
|
|
|
[
|
|
|
|
|
|
'name' => 'hidebar',
|
|
|
|
|
|
'showHide' => 'showhidebar',
|
|
|
|
|
|
'default' => false,
|
|
|
|
|
|
]
|
|
|
|
|
|
],
|
|
|
|
|
|
],
|
|
|
|
|
|
$this->changesListSpecialPage->getFilterGroupDefinitionFromLegacyCustomFilters(
|
|
|
|
|
|
$customFilters
|
|
|
|
|
|
)
|
|
|
|
|
|
);
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
public function testGetStructuredFilterJsData() {
|
2016-12-06 15:25:35 +00:00
|
|
|
|
$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' => function () {
|
|
|
|
|
|
},
|
|
|
|
|
|
'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' => [],
|
|
|
|
|
|
],
|
|
|
|
|
|
[
|
|
|
|
|
|
'name' => 'hidefoo',
|
|
|
|
|
|
'label' => 'foo-label',
|
|
|
|
|
|
'description' => 'foo-description',
|
|
|
|
|
|
'default' => true,
|
|
|
|
|
|
'priority' => 2,
|
|
|
|
|
|
'cssClass' => null,
|
|
|
|
|
|
'conflicts' => [],
|
|
|
|
|
|
'subset' => [],
|
|
|
|
|
|
],
|
|
|
|
|
|
],
|
|
|
|
|
|
'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' => [],
|
|
|
|
|
|
],
|
|
|
|
|
|
[
|
|
|
|
|
|
'name' => 'garply',
|
|
|
|
|
|
'label' => 'garply-label',
|
|
|
|
|
|
'description' => 'garply-description',
|
|
|
|
|
|
'cssClass' => null,
|
|
|
|
|
|
'priority' => -3,
|
|
|
|
|
|
'conflicts' => [],
|
|
|
|
|
|
'subset' => [],
|
|
|
|
|
|
],
|
|
|
|
|
|
],
|
|
|
|
|
|
'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',
|
|
|
|
|
|
],
|
|
|
|
|
|
],
|
|
|
|
|
|
];
|
|
|
|
|
|
}
|
2017-04-10 17:23:45 +00:00
|
|
|
|
|
|
|
|
|
|
public function provideGetFilterConflicts() {
|
|
|
|
|
|
return [
|
|
|
|
|
|
[
|
|
|
|
|
|
"parameters" => [],
|
|
|
|
|
|
"expectedConflicts" => false,
|
|
|
|
|
|
],
|
|
|
|
|
|
[
|
|
|
|
|
|
"parameters" => [
|
|
|
|
|
|
"hideliu" => true,
|
|
|
|
|
|
"userExpLevel" => "newcomer",
|
|
|
|
|
|
],
|
2017-07-14 12:07:41 +00:00
|
|
|
|
"expectedConflicts" => false,
|
2017-04-10 17:23:45 +00:00
|
|
|
|
],
|
|
|
|
|
|
[
|
|
|
|
|
|
"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()
|
|
|
|
|
|
);
|
|
|
|
|
|
}
|
2016-12-06 15:25:35 +00:00
|
|
|
|
|
|
|
|
|
|
public function validateOptionsProvider() {
|
|
|
|
|
|
return [
|
|
|
|
|
|
[
|
|
|
|
|
|
[ 'hideanons' => 1, 'hideliu' => 1, 'hidebots' => 1 ],
|
|
|
|
|
|
true,
|
|
|
|
|
|
[ 'hideliu' => 1, 'hidebots' => 1, ],
|
|
|
|
|
|
],
|
|
|
|
|
|
|
|
|
|
|
|
[
|
|
|
|
|
|
[ 'hideanons' => 1, 'hideliu' => 1, 'hidebots' => 0 ],
|
|
|
|
|
|
true,
|
|
|
|
|
|
[ 'hidebots' => 0, 'hidehumans' => 1 ],
|
|
|
|
|
|
],
|
|
|
|
|
|
|
|
|
|
|
|
[
|
|
|
|
|
|
[ 'hidemyself' => 1, 'hidebyothers' => 1 ],
|
|
|
|
|
|
true,
|
|
|
|
|
|
[],
|
|
|
|
|
|
],
|
|
|
|
|
|
[
|
|
|
|
|
|
[ 'hidebots' => 1, 'hidehumans' => 1 ],
|
|
|
|
|
|
true,
|
|
|
|
|
|
[],
|
|
|
|
|
|
],
|
|
|
|
|
|
[
|
|
|
|
|
|
[ 'hidepatrolled' => 1, 'hideunpatrolled' => 1 ],
|
|
|
|
|
|
true,
|
|
|
|
|
|
[],
|
|
|
|
|
|
],
|
|
|
|
|
|
[
|
|
|
|
|
|
[ 'hideminor' => 1, 'hidemajor' => 1 ],
|
|
|
|
|
|
true,
|
|
|
|
|
|
[],
|
|
|
|
|
|
],
|
|
|
|
|
|
[
|
|
|
|
|
|
// changeType
|
|
|
|
|
|
[ 'hidepageedits' => 1, 'hidenewpages' => 1, 'hidecategorization' => 1, 'hidelog' => 1, ],
|
|
|
|
|
|
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
|
|
|
|
}
|