1
0
Fork 0
mirror of https://we.phorge.it/source/phorge.git synced 2024-11-29 02:02:41 +01:00
phorge-phorge/src/applications/differential/query/DifferentialRevisionSearchEngine.php

282 lines
8.1 KiB
PHP
Raw Normal View History

Use ApplicationSearch in Differential Summary: Ref T603. Ref T2625. Fixes T3241. Depends on D5451. Depends on D6346. @wez, this changes the Differential revision list UI substantially and may generate a lot of bikeshedding / who-moved-my-cheese churn. See T3417 for context, for example. The motivations for this change are: - The list now works on devices, like phones and tablets. This is a requirement to make the rest of Differential work on devices. - Although ApplicationSearch intentionally presents a simpler interface initially and some options which were one click away before aren't now, it is much more powerful than the search it replaces and allows users to build, save, share, fork, edit, and customize a much wider range of queries. Users who used the old filters frequently can use Advanced Search -> Save Custom Query to create new versions of them, and of any other query. "Edit Queries.." allows users to remove and reorder queries, including builtin queries. Basically, there are like three things which have gone from "1-click" to "a few clicks", and ten trillion things which have gone from "hard/impossible" to "relatively easy". The local screenshots look a bit iffy, but I think a lot of this is the fakenesss of my test data. If they still feel iffy in production we can tweak them until they feel good, like we did for Maniphest. Test Plan: {F48477} {F48478} Reviewers: btrahan, chad, wez Reviewed By: btrahan CC: aran, s Maniphest Tasks: T603, T2625, T3241 Differential Revision: https://secure.phabricator.com/D6347
2013-07-03 15:11:07 +02:00
<?php
final class DifferentialRevisionSearchEngine
extends PhabricatorApplicationSearchEngine {
public function getResultTypeDescription() {
return pht('Differential Revisions');
}
public function getApplicationClassName() {
return 'PhabricatorDifferentialApplication';
}
Introduce search result buckets Summary: Ref T10939. Currently, Differential hard-codes some behaviors for the "active" filter. This introduces "buckets" to make this grouping behavior more general/flexible. The buckets don't actually do any grouping yet, this just gets rid of the `$query === 'active'` stuff so far. These buckets change the page size to a large value, becuase pagination won't currently work with bucketing. The problem is that we normally paginate by selecting one more result than we need: so if we're building a page of size 10, we'll select 11 results. This is fast, and if we get 11 back, we know there's a next page with at least one result on it. With buckets, we can't do this, since our 11 results might come back in these buckets: - A, B, C, A, C, C, A, A, B, B, (B) So we know there are more results, and we know that bucket B has more results, but we have no clue if bucket A and bucket C have more results or not (or if there's anything in bucket D, etc). We might need to select a thousand more results to get the first (D) or the next (A). So we could render something like "Some buckets have more results, click here to go to the next page", but users would normally expect to be able to see "This specific bucket, A, has more results.", and we can't do that without a lot more work. It doesn't really matter for revisions, because almost no one has 1K of them, but this may need to be resolved eventually. (I have some OK-ish ideas for resolving it but nothing I'm particularly happy with.) Test Plan: {F1376542} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10939 Differential Revision: https://secure.phabricator.com/D15923
2016-05-15 18:46:38 +02:00
protected function newResultBuckets() {
return DifferentialRevisionResultBucket::getAllResultBuckets();
}
public function newQuery() {
return id(new DifferentialRevisionQuery())
->needFlags(true)
->needDrafts(true)
->needRelationships(true)
->needReviewerStatus(true);
}
protected function buildQueryFromParameters(array $map) {
$query = $this->newQuery();
if ($map['responsiblePHIDs']) {
$query->withResponsibleUsers($map['responsiblePHIDs']);
Use ApplicationSearch in Differential Summary: Ref T603. Ref T2625. Fixes T3241. Depends on D5451. Depends on D6346. @wez, this changes the Differential revision list UI substantially and may generate a lot of bikeshedding / who-moved-my-cheese churn. See T3417 for context, for example. The motivations for this change are: - The list now works on devices, like phones and tablets. This is a requirement to make the rest of Differential work on devices. - Although ApplicationSearch intentionally presents a simpler interface initially and some options which were one click away before aren't now, it is much more powerful than the search it replaces and allows users to build, save, share, fork, edit, and customize a much wider range of queries. Users who used the old filters frequently can use Advanced Search -> Save Custom Query to create new versions of them, and of any other query. "Edit Queries.." allows users to remove and reorder queries, including builtin queries. Basically, there are like three things which have gone from "1-click" to "a few clicks", and ten trillion things which have gone from "hard/impossible" to "relatively easy". The local screenshots look a bit iffy, but I think a lot of this is the fakenesss of my test data. If they still feel iffy in production we can tweak them until they feel good, like we did for Maniphest. Test Plan: {F48477} {F48478} Reviewers: btrahan, chad, wez Reviewed By: btrahan CC: aran, s Maniphest Tasks: T603, T2625, T3241 Differential Revision: https://secure.phabricator.com/D6347
2013-07-03 15:11:07 +02:00
}
if ($map['authorPHIDs']) {
$query->withAuthors($map['authorPHIDs']);
Use ApplicationSearch in Differential Summary: Ref T603. Ref T2625. Fixes T3241. Depends on D5451. Depends on D6346. @wez, this changes the Differential revision list UI substantially and may generate a lot of bikeshedding / who-moved-my-cheese churn. See T3417 for context, for example. The motivations for this change are: - The list now works on devices, like phones and tablets. This is a requirement to make the rest of Differential work on devices. - Although ApplicationSearch intentionally presents a simpler interface initially and some options which were one click away before aren't now, it is much more powerful than the search it replaces and allows users to build, save, share, fork, edit, and customize a much wider range of queries. Users who used the old filters frequently can use Advanced Search -> Save Custom Query to create new versions of them, and of any other query. "Edit Queries.." allows users to remove and reorder queries, including builtin queries. Basically, there are like three things which have gone from "1-click" to "a few clicks", and ten trillion things which have gone from "hard/impossible" to "relatively easy". The local screenshots look a bit iffy, but I think a lot of this is the fakenesss of my test data. If they still feel iffy in production we can tweak them until they feel good, like we did for Maniphest. Test Plan: {F48477} {F48478} Reviewers: btrahan, chad, wez Reviewed By: btrahan CC: aran, s Maniphest Tasks: T603, T2625, T3241 Differential Revision: https://secure.phabricator.com/D6347
2013-07-03 15:11:07 +02:00
}
if ($map['reviewerPHIDs']) {
$query->withReviewers($map['reviewerPHIDs']);
Use ApplicationSearch in Differential Summary: Ref T603. Ref T2625. Fixes T3241. Depends on D5451. Depends on D6346. @wez, this changes the Differential revision list UI substantially and may generate a lot of bikeshedding / who-moved-my-cheese churn. See T3417 for context, for example. The motivations for this change are: - The list now works on devices, like phones and tablets. This is a requirement to make the rest of Differential work on devices. - Although ApplicationSearch intentionally presents a simpler interface initially and some options which were one click away before aren't now, it is much more powerful than the search it replaces and allows users to build, save, share, fork, edit, and customize a much wider range of queries. Users who used the old filters frequently can use Advanced Search -> Save Custom Query to create new versions of them, and of any other query. "Edit Queries.." allows users to remove and reorder queries, including builtin queries. Basically, there are like three things which have gone from "1-click" to "a few clicks", and ten trillion things which have gone from "hard/impossible" to "relatively easy". The local screenshots look a bit iffy, but I think a lot of this is the fakenesss of my test data. If they still feel iffy in production we can tweak them until they feel good, like we did for Maniphest. Test Plan: {F48477} {F48478} Reviewers: btrahan, chad, wez Reviewed By: btrahan CC: aran, s Maniphest Tasks: T603, T2625, T3241 Differential Revision: https://secure.phabricator.com/D6347
2013-07-03 15:11:07 +02:00
}
if ($map['repositoryPHIDs']) {
$query->withRepositoryPHIDs($map['repositoryPHIDs']);
}
if ($map['status']) {
$query->withStatus($map['status']);
Use ApplicationSearch in Differential Summary: Ref T603. Ref T2625. Fixes T3241. Depends on D5451. Depends on D6346. @wez, this changes the Differential revision list UI substantially and may generate a lot of bikeshedding / who-moved-my-cheese churn. See T3417 for context, for example. The motivations for this change are: - The list now works on devices, like phones and tablets. This is a requirement to make the rest of Differential work on devices. - Although ApplicationSearch intentionally presents a simpler interface initially and some options which were one click away before aren't now, it is much more powerful than the search it replaces and allows users to build, save, share, fork, edit, and customize a much wider range of queries. Users who used the old filters frequently can use Advanced Search -> Save Custom Query to create new versions of them, and of any other query. "Edit Queries.." allows users to remove and reorder queries, including builtin queries. Basically, there are like three things which have gone from "1-click" to "a few clicks", and ten trillion things which have gone from "hard/impossible" to "relatively easy". The local screenshots look a bit iffy, but I think a lot of this is the fakenesss of my test data. If they still feel iffy in production we can tweak them until they feel good, like we did for Maniphest. Test Plan: {F48477} {F48478} Reviewers: btrahan, chad, wez Reviewed By: btrahan CC: aran, s Maniphest Tasks: T603, T2625, T3241 Differential Revision: https://secure.phabricator.com/D6347
2013-07-03 15:11:07 +02:00
}
return $query;
}
protected function buildCustomSearchFields() {
return array(
id(new PhabricatorSearchDatasourceField())
->setLabel(pht('Responsible Users'))
->setKey('responsiblePHIDs')
->setAliases(array('responsiblePHID', 'responsibles', 'responsible'))
->setDatasource(new DifferentialResponsibleDatasource())
->setDescription(
pht('Find revisions that a given user is responsible for.')),
id(new PhabricatorUsersSearchField())
->setLabel(pht('Authors'))
->setKey('authorPHIDs')
->setAliases(array('author', 'authors', 'authorPHID'))
->setDescription(
pht('Find revisions with specific authors.')),
id(new PhabricatorSearchDatasourceField())
->setLabel(pht('Reviewers'))
->setKey('reviewerPHIDs')
->setAliases(array('reviewer', 'reviewers', 'reviewerPHID'))
->setDatasource(new DiffusionAuditorFunctionDatasource())
->setDescription(
pht('Find revisions with specific reviewers.')),
id(new PhabricatorSearchDatasourceField())
->setLabel(pht('Repositories'))
->setKey('repositoryPHIDs')
->setAliases(array('repository', 'repositories', 'repositoryPHID'))
->setDatasource(new DifferentialRepositoryDatasource())
->setDescription(
pht('Find revisions from specific repositories.')),
id(new PhabricatorSearchSelectField())
->setLabel(pht('Status'))
->setKey('status')
->setOptions($this->getStatusOptions())
->setDescription(
pht('Find revisions with particular statuses.')),
);
Use ApplicationSearch in Differential Summary: Ref T603. Ref T2625. Fixes T3241. Depends on D5451. Depends on D6346. @wez, this changes the Differential revision list UI substantially and may generate a lot of bikeshedding / who-moved-my-cheese churn. See T3417 for context, for example. The motivations for this change are: - The list now works on devices, like phones and tablets. This is a requirement to make the rest of Differential work on devices. - Although ApplicationSearch intentionally presents a simpler interface initially and some options which were one click away before aren't now, it is much more powerful than the search it replaces and allows users to build, save, share, fork, edit, and customize a much wider range of queries. Users who used the old filters frequently can use Advanced Search -> Save Custom Query to create new versions of them, and of any other query. "Edit Queries.." allows users to remove and reorder queries, including builtin queries. Basically, there are like three things which have gone from "1-click" to "a few clicks", and ten trillion things which have gone from "hard/impossible" to "relatively easy". The local screenshots look a bit iffy, but I think a lot of this is the fakenesss of my test data. If they still feel iffy in production we can tweak them until they feel good, like we did for Maniphest. Test Plan: {F48477} {F48478} Reviewers: btrahan, chad, wez Reviewed By: btrahan CC: aran, s Maniphest Tasks: T603, T2625, T3241 Differential Revision: https://secure.phabricator.com/D6347
2013-07-03 15:11:07 +02:00
}
protected function getURI($path) {
return '/differential/'.$path;
}
protected function getBuiltinQueryNames() {
Use ApplicationSearch in Differential Summary: Ref T603. Ref T2625. Fixes T3241. Depends on D5451. Depends on D6346. @wez, this changes the Differential revision list UI substantially and may generate a lot of bikeshedding / who-moved-my-cheese churn. See T3417 for context, for example. The motivations for this change are: - The list now works on devices, like phones and tablets. This is a requirement to make the rest of Differential work on devices. - Although ApplicationSearch intentionally presents a simpler interface initially and some options which were one click away before aren't now, it is much more powerful than the search it replaces and allows users to build, save, share, fork, edit, and customize a much wider range of queries. Users who used the old filters frequently can use Advanced Search -> Save Custom Query to create new versions of them, and of any other query. "Edit Queries.." allows users to remove and reorder queries, including builtin queries. Basically, there are like three things which have gone from "1-click" to "a few clicks", and ten trillion things which have gone from "hard/impossible" to "relatively easy". The local screenshots look a bit iffy, but I think a lot of this is the fakenesss of my test data. If they still feel iffy in production we can tweak them until they feel good, like we did for Maniphest. Test Plan: {F48477} {F48478} Reviewers: btrahan, chad, wez Reviewed By: btrahan CC: aran, s Maniphest Tasks: T603, T2625, T3241 Differential Revision: https://secure.phabricator.com/D6347
2013-07-03 15:11:07 +02:00
$names = array();
if ($this->requireViewer()->isLoggedIn()) {
$names['active'] = pht('Active Revisions');
$names['authored'] = pht('Authored');
Use ApplicationSearch in Differential Summary: Ref T603. Ref T2625. Fixes T3241. Depends on D5451. Depends on D6346. @wez, this changes the Differential revision list UI substantially and may generate a lot of bikeshedding / who-moved-my-cheese churn. See T3417 for context, for example. The motivations for this change are: - The list now works on devices, like phones and tablets. This is a requirement to make the rest of Differential work on devices. - Although ApplicationSearch intentionally presents a simpler interface initially and some options which were one click away before aren't now, it is much more powerful than the search it replaces and allows users to build, save, share, fork, edit, and customize a much wider range of queries. Users who used the old filters frequently can use Advanced Search -> Save Custom Query to create new versions of them, and of any other query. "Edit Queries.." allows users to remove and reorder queries, including builtin queries. Basically, there are like three things which have gone from "1-click" to "a few clicks", and ten trillion things which have gone from "hard/impossible" to "relatively easy". The local screenshots look a bit iffy, but I think a lot of this is the fakenesss of my test data. If they still feel iffy in production we can tweak them until they feel good, like we did for Maniphest. Test Plan: {F48477} {F48478} Reviewers: btrahan, chad, wez Reviewed By: btrahan CC: aran, s Maniphest Tasks: T603, T2625, T3241 Differential Revision: https://secure.phabricator.com/D6347
2013-07-03 15:11:07 +02:00
}
$names['all'] = pht('All Revisions');
return $names;
}
public function buildSavedQueryFromBuiltin($query_key) {
$query = $this->newSavedQuery();
$query->setQueryKey($query_key);
$viewer = $this->requireViewer();
switch ($query_key) {
case 'active':
Introduce search result buckets Summary: Ref T10939. Currently, Differential hard-codes some behaviors for the "active" filter. This introduces "buckets" to make this grouping behavior more general/flexible. The buckets don't actually do any grouping yet, this just gets rid of the `$query === 'active'` stuff so far. These buckets change the page size to a large value, becuase pagination won't currently work with bucketing. The problem is that we normally paginate by selecting one more result than we need: so if we're building a page of size 10, we'll select 11 results. This is fast, and if we get 11 back, we know there's a next page with at least one result on it. With buckets, we can't do this, since our 11 results might come back in these buckets: - A, B, C, A, C, C, A, A, B, B, (B) So we know there are more results, and we know that bucket B has more results, but we have no clue if bucket A and bucket C have more results or not (or if there's anything in bucket D, etc). We might need to select a thousand more results to get the first (D) or the next (A). So we could render something like "Some buckets have more results, click here to go to the next page", but users would normally expect to be able to see "This specific bucket, A, has more results.", and we can't do that without a lot more work. It doesn't really matter for revisions, because almost no one has 1K of them, but this may need to be resolved eventually. (I have some OK-ish ideas for resolving it but nothing I'm particularly happy with.) Test Plan: {F1376542} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10939 Differential Revision: https://secure.phabricator.com/D15923
2016-05-15 18:46:38 +02:00
$bucket_key = DifferentialRevisionRequiredActionResultBucket::BUCKETKEY;
Use ApplicationSearch in Differential Summary: Ref T603. Ref T2625. Fixes T3241. Depends on D5451. Depends on D6346. @wez, this changes the Differential revision list UI substantially and may generate a lot of bikeshedding / who-moved-my-cheese churn. See T3417 for context, for example. The motivations for this change are: - The list now works on devices, like phones and tablets. This is a requirement to make the rest of Differential work on devices. - Although ApplicationSearch intentionally presents a simpler interface initially and some options which were one click away before aren't now, it is much more powerful than the search it replaces and allows users to build, save, share, fork, edit, and customize a much wider range of queries. Users who used the old filters frequently can use Advanced Search -> Save Custom Query to create new versions of them, and of any other query. "Edit Queries.." allows users to remove and reorder queries, including builtin queries. Basically, there are like three things which have gone from "1-click" to "a few clicks", and ten trillion things which have gone from "hard/impossible" to "relatively easy". The local screenshots look a bit iffy, but I think a lot of this is the fakenesss of my test data. If they still feel iffy in production we can tweak them until they feel good, like we did for Maniphest. Test Plan: {F48477} {F48478} Reviewers: btrahan, chad, wez Reviewed By: btrahan CC: aran, s Maniphest Tasks: T603, T2625, T3241 Differential Revision: https://secure.phabricator.com/D6347
2013-07-03 15:11:07 +02:00
return $query
->setParameter('responsiblePHIDs', array($viewer->getPHID()))
Introduce search result buckets Summary: Ref T10939. Currently, Differential hard-codes some behaviors for the "active" filter. This introduces "buckets" to make this grouping behavior more general/flexible. The buckets don't actually do any grouping yet, this just gets rid of the `$query === 'active'` stuff so far. These buckets change the page size to a large value, becuase pagination won't currently work with bucketing. The problem is that we normally paginate by selecting one more result than we need: so if we're building a page of size 10, we'll select 11 results. This is fast, and if we get 11 back, we know there's a next page with at least one result on it. With buckets, we can't do this, since our 11 results might come back in these buckets: - A, B, C, A, C, C, A, A, B, B, (B) So we know there are more results, and we know that bucket B has more results, but we have no clue if bucket A and bucket C have more results or not (or if there's anything in bucket D, etc). We might need to select a thousand more results to get the first (D) or the next (A). So we could render something like "Some buckets have more results, click here to go to the next page", but users would normally expect to be able to see "This specific bucket, A, has more results.", and we can't do that without a lot more work. It doesn't really matter for revisions, because almost no one has 1K of them, but this may need to be resolved eventually. (I have some OK-ish ideas for resolving it but nothing I'm particularly happy with.) Test Plan: {F1376542} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10939 Differential Revision: https://secure.phabricator.com/D15923
2016-05-15 18:46:38 +02:00
->setParameter('status', DifferentialRevisionQuery::STATUS_OPEN)
->setParameter('bucket', $bucket_key);
case 'authored':
return $query
->setParameter('authorPHIDs', array($viewer->getPHID()));
Use ApplicationSearch in Differential Summary: Ref T603. Ref T2625. Fixes T3241. Depends on D5451. Depends on D6346. @wez, this changes the Differential revision list UI substantially and may generate a lot of bikeshedding / who-moved-my-cheese churn. See T3417 for context, for example. The motivations for this change are: - The list now works on devices, like phones and tablets. This is a requirement to make the rest of Differential work on devices. - Although ApplicationSearch intentionally presents a simpler interface initially and some options which were one click away before aren't now, it is much more powerful than the search it replaces and allows users to build, save, share, fork, edit, and customize a much wider range of queries. Users who used the old filters frequently can use Advanced Search -> Save Custom Query to create new versions of them, and of any other query. "Edit Queries.." allows users to remove and reorder queries, including builtin queries. Basically, there are like three things which have gone from "1-click" to "a few clicks", and ten trillion things which have gone from "hard/impossible" to "relatively easy". The local screenshots look a bit iffy, but I think a lot of this is the fakenesss of my test data. If they still feel iffy in production we can tweak them until they feel good, like we did for Maniphest. Test Plan: {F48477} {F48478} Reviewers: btrahan, chad, wez Reviewed By: btrahan CC: aran, s Maniphest Tasks: T603, T2625, T3241 Differential Revision: https://secure.phabricator.com/D6347
2013-07-03 15:11:07 +02:00
case 'all':
return $query;
}
return parent::buildSavedQueryFromBuiltin($query_key);
}
private function getStatusOptions() {
return array(
DifferentialRevisionQuery::STATUS_ANY => pht('All'),
DifferentialRevisionQuery::STATUS_OPEN => pht('Open'),
DifferentialRevisionQuery::STATUS_ACCEPTED => pht('Accepted'),
DifferentialRevisionQuery::STATUS_NEEDS_REVIEW => pht('Needs Review'),
DifferentialRevisionQuery::STATUS_NEEDS_REVISION => pht('Needs Revision'),
DifferentialRevisionQuery::STATUS_CLOSED => pht('Closed'),
DifferentialRevisionQuery::STATUS_ABANDONED => pht('Abandoned'),
Use ApplicationSearch in Differential Summary: Ref T603. Ref T2625. Fixes T3241. Depends on D5451. Depends on D6346. @wez, this changes the Differential revision list UI substantially and may generate a lot of bikeshedding / who-moved-my-cheese churn. See T3417 for context, for example. The motivations for this change are: - The list now works on devices, like phones and tablets. This is a requirement to make the rest of Differential work on devices. - Although ApplicationSearch intentionally presents a simpler interface initially and some options which were one click away before aren't now, it is much more powerful than the search it replaces and allows users to build, save, share, fork, edit, and customize a much wider range of queries. Users who used the old filters frequently can use Advanced Search -> Save Custom Query to create new versions of them, and of any other query. "Edit Queries.." allows users to remove and reorder queries, including builtin queries. Basically, there are like three things which have gone from "1-click" to "a few clicks", and ten trillion things which have gone from "hard/impossible" to "relatively easy". The local screenshots look a bit iffy, but I think a lot of this is the fakenesss of my test data. If they still feel iffy in production we can tweak them until they feel good, like we did for Maniphest. Test Plan: {F48477} {F48478} Reviewers: btrahan, chad, wez Reviewed By: btrahan CC: aran, s Maniphest Tasks: T603, T2625, T3241 Differential Revision: https://secure.phabricator.com/D6347
2013-07-03 15:11:07 +02:00
);
}
protected function renderResultList(
array $revisions,
PhabricatorSavedQuery $query,
array $handles) {
assert_instances_of($revisions, 'DifferentialRevision');
$viewer = $this->requireViewer();
$template = id(new DifferentialRevisionListView())
->setUser($viewer)
->setNoBox($this->isPanelContext());
Introduce search result buckets Summary: Ref T10939. Currently, Differential hard-codes some behaviors for the "active" filter. This introduces "buckets" to make this grouping behavior more general/flexible. The buckets don't actually do any grouping yet, this just gets rid of the `$query === 'active'` stuff so far. These buckets change the page size to a large value, becuase pagination won't currently work with bucketing. The problem is that we normally paginate by selecting one more result than we need: so if we're building a page of size 10, we'll select 11 results. This is fast, and if we get 11 back, we know there's a next page with at least one result on it. With buckets, we can't do this, since our 11 results might come back in these buckets: - A, B, C, A, C, C, A, A, B, B, (B) So we know there are more results, and we know that bucket B has more results, but we have no clue if bucket A and bucket C have more results or not (or if there's anything in bucket D, etc). We might need to select a thousand more results to get the first (D) or the next (A). So we could render something like "Some buckets have more results, click here to go to the next page", but users would normally expect to be able to see "This specific bucket, A, has more results.", and we can't do that without a lot more work. It doesn't really matter for revisions, because almost no one has 1K of them, but this may need to be resolved eventually. (I have some OK-ish ideas for resolving it but nothing I'm particularly happy with.) Test Plan: {F1376542} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10939 Differential Revision: https://secure.phabricator.com/D15923
2016-05-15 18:46:38 +02:00
$bucket = $this->getResultBucket($query);
$unlanded = $this->loadUnlandedDependencies($revisions);
$views = array();
Introduce search result buckets Summary: Ref T10939. Currently, Differential hard-codes some behaviors for the "active" filter. This introduces "buckets" to make this grouping behavior more general/flexible. The buckets don't actually do any grouping yet, this just gets rid of the `$query === 'active'` stuff so far. These buckets change the page size to a large value, becuase pagination won't currently work with bucketing. The problem is that we normally paginate by selecting one more result than we need: so if we're building a page of size 10, we'll select 11 results. This is fast, and if we get 11 back, we know there's a next page with at least one result on it. With buckets, we can't do this, since our 11 results might come back in these buckets: - A, B, C, A, C, C, A, A, B, B, (B) So we know there are more results, and we know that bucket B has more results, but we have no clue if bucket A and bucket C have more results or not (or if there's anything in bucket D, etc). We might need to select a thousand more results to get the first (D) or the next (A). So we could render something like "Some buckets have more results, click here to go to the next page", but users would normally expect to be able to see "This specific bucket, A, has more results.", and we can't do that without a lot more work. It doesn't really matter for revisions, because almost no one has 1K of them, but this may need to be resolved eventually. (I have some OK-ish ideas for resolving it but nothing I'm particularly happy with.) Test Plan: {F1376542} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10939 Differential Revision: https://secure.phabricator.com/D15923
2016-05-15 18:46:38 +02:00
if ($bucket) {
$bucket->setViewer($viewer);
try {
$groups = $bucket->newResultGroups($query, $revisions);
foreach ($groups as $group) {
$views[] = id(clone $template)
->setHeader($group->getName())
->setNoDataString($group->getNoDataString())
->setRevisions($group->getObjects());
}
} catch (Exception $ex) {
$this->addError($ex->getMessage());
}
} else {
$views[] = id(clone $template)
->setRevisions($revisions)
->setHandles(array());
}
$phids = array_mergev(mpull($views, 'getRequiredHandlePHIDs'));
if ($phids) {
$handles = id(new PhabricatorHandleQuery())
->setViewer($viewer)
->withPHIDs($phids)
->execute();
} else {
$handles = array();
}
foreach ($views as $view) {
$view->setHandles($handles);
$view->setUnlandedDependencies($unlanded);
}
if (count($views) == 1) {
// Reduce this to a PHUIObjectItemListView so we can get the free
// support from ApplicationSearch.
$list = head($views)->render();
} else {
$list = $views;
}
$result = new PhabricatorApplicationSearchResultView();
$result->setContent($list);
return $result;
}
protected function getNewUserBody() {
$create_button = id(new PHUIButtonView())
->setTag('a')
->setText(pht('Create a Diff'))
->setHref('/differential/diff/create/')
->setColor(PHUIButtonView::GREEN);
$icon = $this->getApplication()->getIcon();
$app_name = $this->getApplication()->getName();
$view = id(new PHUIBigInfoView())
->setIcon($icon)
->setTitle(pht('Welcome to %s', $app_name))
->setDescription(
pht('Pre-commit code review. Revisions that are waiting on your input '.
'will appear here.'))
->addAction($create_button);
return $view;
}
private function loadUnlandedDependencies(array $revisions) {
$status_accepted = ArcanistDifferentialRevisionStatus::ACCEPTED;
$phids = array();
foreach ($revisions as $revision) {
if ($revision->getStatus() != $status_accepted) {
continue;
}
$phids[] = $revision->getPHID();
}
if (!$phids) {
return array();
}
$query = id(new PhabricatorEdgeQuery())
->withSourcePHIDs($phids)
->withEdgeTypes(
array(
DifferentialRevisionDependsOnRevisionEdgeType::EDGECONST,
));
$query->execute();
$revision_phids = $query->getDestinationPHIDs();
if (!$revision_phids) {
return array();
}
$viewer = $this->requireViewer();
$blocking_revisions = id(new DifferentialRevisionQuery())
->setViewer($viewer)
->withPHIDs($revision_phids)
->withStatus(DifferentialRevisionQuery::STATUS_OPEN)
->execute();
$blocking_revisions = mpull($blocking_revisions, null, 'getPHID');
$result = array();
foreach ($revisions as $revision) {
$revision_phid = $revision->getPHID();
$blocking_phids = $query->getDestinationPHIDs(array($revision_phid));
$blocking = array_select_keys($blocking_revisions, $blocking_phids);
if ($blocking) {
$result[$revision_phid] = $blocking;
}
}
return $result;
}
Use ApplicationSearch in Differential Summary: Ref T603. Ref T2625. Fixes T3241. Depends on D5451. Depends on D6346. @wez, this changes the Differential revision list UI substantially and may generate a lot of bikeshedding / who-moved-my-cheese churn. See T3417 for context, for example. The motivations for this change are: - The list now works on devices, like phones and tablets. This is a requirement to make the rest of Differential work on devices. - Although ApplicationSearch intentionally presents a simpler interface initially and some options which were one click away before aren't now, it is much more powerful than the search it replaces and allows users to build, save, share, fork, edit, and customize a much wider range of queries. Users who used the old filters frequently can use Advanced Search -> Save Custom Query to create new versions of them, and of any other query. "Edit Queries.." allows users to remove and reorder queries, including builtin queries. Basically, there are like three things which have gone from "1-click" to "a few clicks", and ten trillion things which have gone from "hard/impossible" to "relatively easy". The local screenshots look a bit iffy, but I think a lot of this is the fakenesss of my test data. If they still feel iffy in production we can tweak them until they feel good, like we did for Maniphest. Test Plan: {F48477} {F48478} Reviewers: btrahan, chad, wez Reviewed By: btrahan CC: aran, s Maniphest Tasks: T603, T2625, T3241 Differential Revision: https://secure.phabricator.com/D6347
2013-07-03 15:11:07 +02:00
}