wiki.techinc.nl/tests/phpunit/includes/specials/SpecialRecentchangesTest.php

112 lines
3.4 KiB
PHP
Raw Normal View History

<?php
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
use MediaWiki\MediaWikiServices;
use Wikimedia\TestingAccessWrapper;
/**
* Test class for SpecialRecentchanges class
*
* @group Database
*
* @covers SpecialRecentChanges
*/
Back-end of new RecentChanges page, refactoring Generate old RC, Related changes (it was already displayed and working on 'Related changes' before this change), and Watchlist/etc. and data for new UI from back-end. This moves everything used for defining the old (unstructured) and new (structured) filters into unified objects, ChangesListFilter and ChangesListFilterGroup (and sub-classes). This includes the query logic (see below) and logic for adding CSS attribution classes. This is a breaking change (for subclasses of ChangesListSpecialpage) due to the signature (and name) change of buildMainQueryConds and doMainQuery. An alternative that I don't think is a breaking change would be to put the filter->DB logic in runMainQueryHook, but then it's doing more than just running a hook. This is because it used to only build $conds here, but it's clear from filterOnUserExperienceLevel filters need more than this. I added all the DB parameters from the hook, but this could be debated. I have an checked and fixed the WMF-deployed extensions affected by this. Other than that, there should be full back-compat (including legacy filters not using the new system). * add hidepatrolled/hideunpatrolled to new UI. * Move userExpLevel from RC to ChangesListSpecialPage. Although for now the structured UI only displays on RC anyway, when it displays on watchlist, it seems we'll want userExpLevel there. Change this to make 'all' exclude unregistered users. * Don't have front-end convert none-selected to 'all' on string_options. * Needs the hideanons/hideliu special redirect to be done before this is merged (T151873) Bug: T152754 Bug: T152797 Change-Id: Iec2d82f6a830403d1c948a280efa58992e0cdee7
2017-02-14 07:55:37 +00:00
class SpecialRecentchangesTest extends AbstractChangesListSpecialPageTestCase {
/**
* @return SpecialRecentChanges
*/
protected function getPage() {
$services = MediaWikiServices::getInstance();
return TestingAccessWrapper::newFromObject(
new SpecialRecentChanges(
$services->getWatchedItemStore(),
$services->getMessageCache(),
$services->getDBLoadBalancer(),
$services->getUserOptionsLookup()
)
);
}
// Below providers should only be for features specific to
// RecentChanges. Otherwise, it should go in ChangesListSpecialPageTest
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 provideParseParameters() {
return [
[ 'limit=123', [ 'limit' => '123' ] ],
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
[ '234', [ 'limit' => '234' ] ],
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
[ 'days=3', [ 'days' => '3' ] ],
[ 'days=0.25', [ 'days' => '0.25' ] ],
[ 'namespace=5', [ 'namespace' => '5' ] ],
[ 'namespace=5|3', [ 'namespace' => '5|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
[ 'tagfilter=foo', [ 'tagfilter' => 'foo' ] ],
[ 'tagfilter=foo;bar', [ 'tagfilter' => 'foo;bar' ] ],
];
}
public function validateOptionsProvider() {
return [
[
// hidebots=1 is default for Special:RecentChanges
[ 'hideanons' => 1, 'hideliu' => 1 ],
true,
[ 'hideliu' => 1 ],
false,
],
];
}
public function testAddWatchlistJoins() {
// Edit a test page so that it shows up in RC.
$testTitle = Title::newFromText( 'Test page' );
$testPage = WikiPage::factory( $testTitle );
$testPage->doEditContent( ContentHandler::makeContent( 'Test content', $testTitle ), '' );
// Set up RC.
$context = new RequestContext;
$context->setTitle( Title::newFromText( __METHOD__ ) );
$context->setUser( $this->getTestUser()->getUser() );
$context->setRequest( new FauxRequest );
// Confirm that the test page is in RC.
$rc1 = $this->getPage();
$rc1->setContext( $context );
$rc1->execute( null );
$this->assertStringContainsString( 'Test page', $rc1->getOutput()->getHTML() );
$this->assertStringContainsString( 'mw-changeslist-line-not-watched', $rc1->getOutput()->getHTML() );
// Watch the page, and check that it's now watched in RC.
$watchedItemStore = MediaWikiServices::getInstance()->getWatchedItemStore();
$watchedItemStore->addWatch( $context->getUser(), $testTitle );
$rc2 = $this->getPage();
$rc2->setContext( $context );
$rc2->execute( null );
$this->assertStringContainsString( 'Test page', $rc2->getOutput()->getHTML() );
$this->assertStringContainsString( 'mw-changeslist-line-watched', $rc2->getOutput()->getHTML() );
// Force a past expiry date on the watchlist item.
$db = wfGetDB( DB_PRIMARY );
$queryConds = [ 'wl_namespace' => $testTitle->getNamespace(), 'wl_title' => $testTitle->getDBkey() ];
$watchedItemId = $db->selectField( 'watchlist', 'wl_id', $queryConds, __METHOD__ );
$db->update(
'watchlist_expiry',
[ 'we_expiry' => $db->timestamp( '20200101000000' ) ],
[ 'we_item' => $watchedItemId ],
__METHOD__
);
// Check that the page is still in RC, but that it's no longer watched.
$rc3 = $this->getPage();
$rc3->setContext( $context );
$rc3->execute( null );
$this->assertStringContainsString( 'Test page', $rc3->getOutput()->getHTML() );
$this->assertStringContainsString( 'mw-changeslist-line-not-watched', $rc3->getOutput()->getHTML() );
}
}