2011-12-16 17:08:18 -08:00
|
|
|
<?php
|
|
|
|
|
2012-09-13 10:15:08 -07:00
|
|
|
final class PhabricatorProjectQuery
|
|
|
|
extends PhabricatorCursorPagedPolicyAwareQuery {
|
2011-12-16 17:08:18 -08:00
|
|
|
|
2012-01-17 16:29:35 -08:00
|
|
|
private $ids;
|
|
|
|
private $phids;
|
2012-08-07 11:54:24 -07:00
|
|
|
private $memberPHIDs;
|
2013-03-08 07:12:24 -08:00
|
|
|
private $slugs;
|
2014-05-22 11:19:03 -07:00
|
|
|
private $phrictionSlugs;
|
2013-10-25 10:16:39 -07:00
|
|
|
private $names;
|
2014-07-17 16:35:54 -07:00
|
|
|
private $datasourceQuery;
|
2011-12-16 17:08:18 -08:00
|
|
|
|
2012-02-07 14:59:38 -08:00
|
|
|
private $status = 'status-any';
|
|
|
|
const STATUS_ANY = 'status-any';
|
|
|
|
const STATUS_OPEN = 'status-open';
|
|
|
|
const STATUS_CLOSED = 'status-closed';
|
|
|
|
const STATUS_ACTIVE = 'status-active';
|
|
|
|
const STATUS_ARCHIVED = 'status-archived';
|
|
|
|
|
2014-05-22 11:19:03 -07:00
|
|
|
private $needSlugs;
|
2012-01-17 16:29:35 -08:00
|
|
|
private $needMembers;
|
2014-05-19 12:40:57 -07:00
|
|
|
private $needWatchers;
|
Migrate project profiles onto projects, and remove ProjectProfile object
Summary:
Ref T4379. Long ago, the "Project" vs "ProjectProfile" split was intended to allow a bunch of special fields on projects without burdening the simple use cases, but CustomField handles that far better and far more generally, and doing this makes using ApplicationTransactions a pain to get right, so get rid of it.
The only remaining field is `profileImagePHID`, which we can just move to the main Project object. This is custom enough that I think it's reasonable not to express it as a custom field.
Test Plan: Created a project, set profile, edited project, viewed in typeahead, ran migration, verified database results.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T4379
Differential Revision: https://secure.phabricator.com/D8183
2014-02-10 14:32:14 -08:00
|
|
|
private $needImages;
|
2012-01-17 16:29:35 -08:00
|
|
|
|
|
|
|
public function withIDs(array $ids) {
|
|
|
|
$this->ids = $ids;
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
|
|
|
public function withPHIDs(array $phids) {
|
|
|
|
$this->phids = $phids;
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
2012-02-07 14:59:38 -08:00
|
|
|
public function withStatus($status) {
|
|
|
|
$this->status = $status;
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
2012-08-07 11:54:24 -07:00
|
|
|
public function withMemberPHIDs(array $member_phids) {
|
|
|
|
$this->memberPHIDs = $member_phids;
|
2011-12-16 17:08:18 -08:00
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
2014-05-22 11:19:03 -07:00
|
|
|
public function withSlugs(array $slugs) {
|
2013-03-08 07:12:24 -08:00
|
|
|
$this->slugs = $slugs;
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
2014-05-22 11:19:03 -07:00
|
|
|
public function withPhrictionSlugs(array $slugs) {
|
|
|
|
$this->phrictionSlugs = $slugs;
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
2013-10-25 10:16:39 -07:00
|
|
|
public function withNames(array $names) {
|
|
|
|
$this->names = $names;
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
2014-07-17 16:35:54 -07:00
|
|
|
public function withDatasourceQuery($string) {
|
|
|
|
$this->datasourceQuery = $string;
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
2012-01-17 16:29:35 -08:00
|
|
|
public function needMembers($need_members) {
|
|
|
|
$this->needMembers = $need_members;
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
2014-05-19 12:40:57 -07:00
|
|
|
public function needWatchers($need_watchers) {
|
|
|
|
$this->needWatchers = $need_watchers;
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
Migrate project profiles onto projects, and remove ProjectProfile object
Summary:
Ref T4379. Long ago, the "Project" vs "ProjectProfile" split was intended to allow a bunch of special fields on projects without burdening the simple use cases, but CustomField handles that far better and far more generally, and doing this makes using ApplicationTransactions a pain to get right, so get rid of it.
The only remaining field is `profileImagePHID`, which we can just move to the main Project object. This is custom enough that I think it's reasonable not to express it as a custom field.
Test Plan: Created a project, set profile, edited project, viewed in typeahead, ran migration, verified database results.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T4379
Differential Revision: https://secure.phabricator.com/D8183
2014-02-10 14:32:14 -08:00
|
|
|
public function needImages($need_images) {
|
|
|
|
$this->needImages = $need_images;
|
2013-10-06 17:07:20 -07:00
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
2014-05-22 11:19:03 -07:00
|
|
|
public function needSlugs($need_slugs) {
|
|
|
|
$this->needSlugs = $need_slugs;
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
2012-08-08 17:10:10 -07:00
|
|
|
protected function getPagingColumn() {
|
|
|
|
return 'name';
|
|
|
|
}
|
|
|
|
|
|
|
|
protected function getPagingValue($result) {
|
|
|
|
return $result->getName();
|
|
|
|
}
|
|
|
|
|
2012-08-11 07:05:45 -07:00
|
|
|
protected function getReversePaging() {
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2013-03-01 11:28:02 -08:00
|
|
|
protected function loadPage() {
|
2012-08-07 11:54:39 -07:00
|
|
|
$table = new PhabricatorProject();
|
2011-12-16 17:08:18 -08:00
|
|
|
$conn_r = $table->establishConnection('r');
|
|
|
|
|
2012-08-11 07:05:01 -07:00
|
|
|
// NOTE: Because visibility checks for projects depend on whether or not
|
|
|
|
// the user is a project member, we always load their membership. If we're
|
|
|
|
// loading all members anyway we can piggyback on that; otherwise we
|
|
|
|
// do an explicit join.
|
|
|
|
|
|
|
|
$select_clause = '';
|
|
|
|
if (!$this->needMembers) {
|
|
|
|
$select_clause = ', vm.dst viewerIsMember';
|
|
|
|
}
|
|
|
|
|
2011-12-16 17:08:18 -08:00
|
|
|
$data = queryfx_all(
|
|
|
|
$conn_r,
|
2012-08-11 07:05:01 -07:00
|
|
|
'SELECT p.* %Q FROM %T p %Q %Q %Q %Q %Q',
|
|
|
|
$select_clause,
|
2011-12-16 17:08:18 -08:00
|
|
|
$table->getTableName(),
|
2012-08-07 18:02:05 -07:00
|
|
|
$this->buildJoinClause($conn_r),
|
|
|
|
$this->buildWhereClause($conn_r),
|
|
|
|
$this->buildGroupClause($conn_r),
|
2012-08-11 07:05:01 -07:00
|
|
|
$this->buildOrderClause($conn_r),
|
2012-08-07 11:54:39 -07:00
|
|
|
$this->buildLimitClause($conn_r));
|
2011-12-16 17:08:18 -08:00
|
|
|
|
2012-01-17 16:29:35 -08:00
|
|
|
$projects = $table->loadAllFromArray($data);
|
|
|
|
|
2012-08-11 07:05:01 -07:00
|
|
|
if ($projects) {
|
|
|
|
$viewer_phid = $this->getViewer()->getPHID();
|
2014-05-19 12:40:57 -07:00
|
|
|
$project_phids = mpull($projects, 'getPHID');
|
|
|
|
|
|
|
|
$member_type = PhabricatorEdgeConfig::TYPE_PROJ_MEMBER;
|
|
|
|
$watcher_type = PhabricatorEdgeConfig::TYPE_OBJECT_HAS_WATCHER;
|
|
|
|
|
|
|
|
$need_edge_types = array();
|
2012-08-11 07:05:01 -07:00
|
|
|
if ($this->needMembers) {
|
2014-05-19 12:40:57 -07:00
|
|
|
$need_edge_types[] = $member_type;
|
2012-08-11 07:05:01 -07:00
|
|
|
} else {
|
|
|
|
foreach ($data as $row) {
|
|
|
|
$projects[$row['id']]->setIsUserMember(
|
|
|
|
$viewer_phid,
|
|
|
|
($row['viewerIsMember'] !== null));
|
|
|
|
}
|
2012-01-17 16:29:35 -08:00
|
|
|
}
|
2014-05-19 12:40:57 -07:00
|
|
|
|
|
|
|
if ($this->needWatchers) {
|
|
|
|
$need_edge_types[] = $watcher_type;
|
|
|
|
}
|
|
|
|
|
|
|
|
if ($need_edge_types) {
|
|
|
|
$edges = id(new PhabricatorEdgeQuery())
|
|
|
|
->withSourcePHIDs($project_phids)
|
|
|
|
->withEdgeTypes($need_edge_types)
|
|
|
|
->execute();
|
|
|
|
|
|
|
|
if ($this->needMembers) {
|
|
|
|
foreach ($projects as $project) {
|
|
|
|
$phid = $project->getPHID();
|
|
|
|
$project->attachMemberPHIDs(
|
|
|
|
array_keys($edges[$phid][$member_type]));
|
|
|
|
$project->setIsUserMember(
|
|
|
|
$viewer_phid,
|
|
|
|
isset($edges[$phid][$member_type][$viewer_phid]));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if ($this->needWatchers) {
|
|
|
|
foreach ($projects as $project) {
|
|
|
|
$phid = $project->getPHID();
|
|
|
|
$project->attachWatcherPHIDs(
|
|
|
|
array_keys($edges[$phid][$watcher_type]));
|
|
|
|
$project->setIsUserWatcher(
|
|
|
|
$viewer_phid,
|
|
|
|
isset($edges[$phid][$watcher_type][$viewer_phid]));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
Fix some file policy issues and add a "Query Workspace"
Summary:
Ref T603. Several issues here:
1. Currently, `FileQuery` does not actually respect object attachment edges when doing policy checks. Everything else works fine, but this was missing an `array_keys()`.
2. Once that's fixed, we hit a bunch of recursion issues. For example, when loading a User we load the profile picture, and then that loads the User, and that loads the profile picture, etc.
3. Introduce a "Query Workspace", which holds objects we know we've loaded and know we can see but haven't finished filtering and/or attaching data to. This allows subqueries to look up objects instead of querying for them.
- We can probably generalize this a bit to make a few other queries more efficient. Pholio currently has a similar (but less general) "mock cache". However, it's keyed by ID instead of PHID so it's not easy to reuse this right now.
This is a bit complex for the problem being solved, but I think it's the cleanest approach and I believe the primitive will be useful in the future.
Test Plan: Looked at pastes, macros, mocks and projects as a logged-in and logged-out user.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T603
Differential Revision: https://secure.phabricator.com/D7309
2013-10-14 14:36:06 -07:00
|
|
|
}
|
2013-10-06 17:07:20 -07:00
|
|
|
|
Fix some file policy issues and add a "Query Workspace"
Summary:
Ref T603. Several issues here:
1. Currently, `FileQuery` does not actually respect object attachment edges when doing policy checks. Everything else works fine, but this was missing an `array_keys()`.
2. Once that's fixed, we hit a bunch of recursion issues. For example, when loading a User we load the profile picture, and then that loads the User, and that loads the profile picture, etc.
3. Introduce a "Query Workspace", which holds objects we know we've loaded and know we can see but haven't finished filtering and/or attaching data to. This allows subqueries to look up objects instead of querying for them.
- We can probably generalize this a bit to make a few other queries more efficient. Pholio currently has a similar (but less general) "mock cache". However, it's keyed by ID instead of PHID so it's not easy to reuse this right now.
This is a bit complex for the problem being solved, but I think it's the cleanest approach and I believe the primitive will be useful in the future.
Test Plan: Looked at pastes, macros, mocks and projects as a logged-in and logged-out user.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T603
Differential Revision: https://secure.phabricator.com/D7309
2013-10-14 14:36:06 -07:00
|
|
|
return $projects;
|
|
|
|
}
|
2013-10-06 17:07:43 -07:00
|
|
|
|
Fix some file policy issues and add a "Query Workspace"
Summary:
Ref T603. Several issues here:
1. Currently, `FileQuery` does not actually respect object attachment edges when doing policy checks. Everything else works fine, but this was missing an `array_keys()`.
2. Once that's fixed, we hit a bunch of recursion issues. For example, when loading a User we load the profile picture, and then that loads the User, and that loads the profile picture, etc.
3. Introduce a "Query Workspace", which holds objects we know we've loaded and know we can see but haven't finished filtering and/or attaching data to. This allows subqueries to look up objects instead of querying for them.
- We can probably generalize this a bit to make a few other queries more efficient. Pholio currently has a similar (but less general) "mock cache". However, it's keyed by ID instead of PHID so it's not easy to reuse this right now.
This is a bit complex for the problem being solved, but I think it's the cleanest approach and I believe the primitive will be useful in the future.
Test Plan: Looked at pastes, macros, mocks and projects as a logged-in and logged-out user.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T603
Differential Revision: https://secure.phabricator.com/D7309
2013-10-14 14:36:06 -07:00
|
|
|
protected function didFilterPage(array $projects) {
|
Migrate project profiles onto projects, and remove ProjectProfile object
Summary:
Ref T4379. Long ago, the "Project" vs "ProjectProfile" split was intended to allow a bunch of special fields on projects without burdening the simple use cases, but CustomField handles that far better and far more generally, and doing this makes using ApplicationTransactions a pain to get right, so get rid of it.
The only remaining field is `profileImagePHID`, which we can just move to the main Project object. This is custom enough that I think it's reasonable not to express it as a custom field.
Test Plan: Created a project, set profile, edited project, viewed in typeahead, ran migration, verified database results.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T4379
Differential Revision: https://secure.phabricator.com/D8183
2014-02-10 14:32:14 -08:00
|
|
|
if ($this->needImages) {
|
Fix some file policy issues and add a "Query Workspace"
Summary:
Ref T603. Several issues here:
1. Currently, `FileQuery` does not actually respect object attachment edges when doing policy checks. Everything else works fine, but this was missing an `array_keys()`.
2. Once that's fixed, we hit a bunch of recursion issues. For example, when loading a User we load the profile picture, and then that loads the User, and that loads the profile picture, etc.
3. Introduce a "Query Workspace", which holds objects we know we've loaded and know we can see but haven't finished filtering and/or attaching data to. This allows subqueries to look up objects instead of querying for them.
- We can probably generalize this a bit to make a few other queries more efficient. Pholio currently has a similar (but less general) "mock cache". However, it's keyed by ID instead of PHID so it's not easy to reuse this right now.
This is a bit complex for the problem being solved, but I think it's the cleanest approach and I believe the primitive will be useful in the future.
Test Plan: Looked at pastes, macros, mocks and projects as a logged-in and logged-out user.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T603
Differential Revision: https://secure.phabricator.com/D7309
2013-10-14 14:36:06 -07:00
|
|
|
$default = null;
|
|
|
|
|
Migrate project profiles onto projects, and remove ProjectProfile object
Summary:
Ref T4379. Long ago, the "Project" vs "ProjectProfile" split was intended to allow a bunch of special fields on projects without burdening the simple use cases, but CustomField handles that far better and far more generally, and doing this makes using ApplicationTransactions a pain to get right, so get rid of it.
The only remaining field is `profileImagePHID`, which we can just move to the main Project object. This is custom enough that I think it's reasonable not to express it as a custom field.
Test Plan: Created a project, set profile, edited project, viewed in typeahead, ran migration, verified database results.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T4379
Differential Revision: https://secure.phabricator.com/D8183
2014-02-10 14:32:14 -08:00
|
|
|
$file_phids = mpull($projects, 'getProfileImagePHID');
|
|
|
|
$files = id(new PhabricatorFileQuery())
|
|
|
|
->setParentQuery($this)
|
|
|
|
->setViewer($this->getViewer())
|
|
|
|
->withPHIDs($file_phids)
|
|
|
|
->execute();
|
|
|
|
$files = mpull($files, null, 'getPHID');
|
Fix some file policy issues and add a "Query Workspace"
Summary:
Ref T603. Several issues here:
1. Currently, `FileQuery` does not actually respect object attachment edges when doing policy checks. Everything else works fine, but this was missing an `array_keys()`.
2. Once that's fixed, we hit a bunch of recursion issues. For example, when loading a User we load the profile picture, and then that loads the User, and that loads the profile picture, etc.
3. Introduce a "Query Workspace", which holds objects we know we've loaded and know we can see but haven't finished filtering and/or attaching data to. This allows subqueries to look up objects instead of querying for them.
- We can probably generalize this a bit to make a few other queries more efficient. Pholio currently has a similar (but less general) "mock cache". However, it's keyed by ID instead of PHID so it's not easy to reuse this right now.
This is a bit complex for the problem being solved, but I think it's the cleanest approach and I believe the primitive will be useful in the future.
Test Plan: Looked at pastes, macros, mocks and projects as a logged-in and logged-out user.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T603
Differential Revision: https://secure.phabricator.com/D7309
2013-10-14 14:36:06 -07:00
|
|
|
foreach ($projects as $project) {
|
Migrate project profiles onto projects, and remove ProjectProfile object
Summary:
Ref T4379. Long ago, the "Project" vs "ProjectProfile" split was intended to allow a bunch of special fields on projects without burdening the simple use cases, but CustomField handles that far better and far more generally, and doing this makes using ApplicationTransactions a pain to get right, so get rid of it.
The only remaining field is `profileImagePHID`, which we can just move to the main Project object. This is custom enough that I think it's reasonable not to express it as a custom field.
Test Plan: Created a project, set profile, edited project, viewed in typeahead, ran migration, verified database results.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T4379
Differential Revision: https://secure.phabricator.com/D8183
2014-02-10 14:32:14 -08:00
|
|
|
$file = idx($files, $project->getProfileImagePHID());
|
|
|
|
if (!$file) {
|
Fix some file policy issues and add a "Query Workspace"
Summary:
Ref T603. Several issues here:
1. Currently, `FileQuery` does not actually respect object attachment edges when doing policy checks. Everything else works fine, but this was missing an `array_keys()`.
2. Once that's fixed, we hit a bunch of recursion issues. For example, when loading a User we load the profile picture, and then that loads the User, and that loads the profile picture, etc.
3. Introduce a "Query Workspace", which holds objects we know we've loaded and know we can see but haven't finished filtering and/or attaching data to. This allows subqueries to look up objects instead of querying for them.
- We can probably generalize this a bit to make a few other queries more efficient. Pholio currently has a similar (but less general) "mock cache". However, it's keyed by ID instead of PHID so it's not easy to reuse this right now.
This is a bit complex for the problem being solved, but I think it's the cleanest approach and I believe the primitive will be useful in the future.
Test Plan: Looked at pastes, macros, mocks and projects as a logged-in and logged-out user.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T603
Differential Revision: https://secure.phabricator.com/D7309
2013-10-14 14:36:06 -07:00
|
|
|
if (!$default) {
|
|
|
|
$default = PhabricatorFile::loadBuiltin(
|
|
|
|
$this->getViewer(),
|
2013-10-17 09:32:34 -07:00
|
|
|
'project.png');
|
2013-10-06 17:07:20 -07:00
|
|
|
}
|
Migrate project profiles onto projects, and remove ProjectProfile object
Summary:
Ref T4379. Long ago, the "Project" vs "ProjectProfile" split was intended to allow a bunch of special fields on projects without burdening the simple use cases, but CustomField handles that far better and far more generally, and doing this makes using ApplicationTransactions a pain to get right, so get rid of it.
The only remaining field is `profileImagePHID`, which we can just move to the main Project object. This is custom enough that I think it's reasonable not to express it as a custom field.
Test Plan: Created a project, set profile, edited project, viewed in typeahead, ran migration, verified database results.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T4379
Differential Revision: https://secure.phabricator.com/D8183
2014-02-10 14:32:14 -08:00
|
|
|
$file = $default;
|
2013-10-06 17:07:20 -07:00
|
|
|
}
|
Migrate project profiles onto projects, and remove ProjectProfile object
Summary:
Ref T4379. Long ago, the "Project" vs "ProjectProfile" split was intended to allow a bunch of special fields on projects without burdening the simple use cases, but CustomField handles that far better and far more generally, and doing this makes using ApplicationTransactions a pain to get right, so get rid of it.
The only remaining field is `profileImagePHID`, which we can just move to the main Project object. This is custom enough that I think it's reasonable not to express it as a custom field.
Test Plan: Created a project, set profile, edited project, viewed in typeahead, ran migration, verified database results.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T4379
Differential Revision: https://secure.phabricator.com/D8183
2014-02-10 14:32:14 -08:00
|
|
|
$project->attachProfileImageFile($file);
|
2013-10-06 17:07:20 -07:00
|
|
|
}
|
2012-01-17 16:29:35 -08:00
|
|
|
}
|
|
|
|
|
2014-05-22 11:19:03 -07:00
|
|
|
if ($this->needSlugs) {
|
|
|
|
$slugs = id(new PhabricatorProjectSlug())
|
|
|
|
->loadAllWhere(
|
|
|
|
'projectPHID IN (%Ls)',
|
|
|
|
mpull($projects, 'getPHID'));
|
|
|
|
$slugs = mgroup($slugs, 'getProjectPHID');
|
|
|
|
foreach ($projects as $project) {
|
|
|
|
$project_slugs = idx($slugs, $project->getPHID(), array());
|
|
|
|
$project->attachSlugs($project_slugs);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-01-17 16:29:35 -08:00
|
|
|
return $projects;
|
|
|
|
}
|
|
|
|
|
|
|
|
private function buildWhereClause($conn_r) {
|
|
|
|
$where = array();
|
|
|
|
|
2012-02-07 14:59:38 -08:00
|
|
|
if ($this->status != self::STATUS_ANY) {
|
|
|
|
switch ($this->status) {
|
|
|
|
case self::STATUS_OPEN:
|
|
|
|
case self::STATUS_ACTIVE:
|
2012-08-07 18:02:05 -07:00
|
|
|
$filter = array(
|
|
|
|
PhabricatorProjectStatus::STATUS_ACTIVE,
|
|
|
|
);
|
2012-02-07 14:59:38 -08:00
|
|
|
break;
|
2012-08-07 18:02:05 -07:00
|
|
|
case self::STATUS_CLOSED:
|
2012-02-07 14:59:38 -08:00
|
|
|
case self::STATUS_ARCHIVED:
|
2012-08-07 18:02:05 -07:00
|
|
|
$filter = array(
|
|
|
|
PhabricatorProjectStatus::STATUS_ARCHIVED,
|
|
|
|
);
|
2012-02-07 14:59:38 -08:00
|
|
|
break;
|
|
|
|
default:
|
|
|
|
throw new Exception(
|
|
|
|
"Unknown project status '{$this->status}'!");
|
|
|
|
}
|
2012-08-07 18:02:05 -07:00
|
|
|
$where[] = qsprintf(
|
|
|
|
$conn_r,
|
|
|
|
'status IN (%Ld)',
|
|
|
|
$filter);
|
2012-02-07 14:59:38 -08:00
|
|
|
}
|
|
|
|
|
2012-01-17 16:29:35 -08:00
|
|
|
if ($this->ids) {
|
|
|
|
$where[] = qsprintf(
|
|
|
|
$conn_r,
|
|
|
|
'id IN (%Ld)',
|
|
|
|
$this->ids);
|
|
|
|
}
|
|
|
|
|
|
|
|
if ($this->phids) {
|
|
|
|
$where[] = qsprintf(
|
|
|
|
$conn_r,
|
|
|
|
'phid IN (%Ls)',
|
|
|
|
$this->phids);
|
|
|
|
}
|
|
|
|
|
2012-08-07 18:02:05 -07:00
|
|
|
if ($this->memberPHIDs) {
|
|
|
|
$where[] = qsprintf(
|
|
|
|
$conn_r,
|
2012-08-11 07:05:01 -07:00
|
|
|
'e.dst IN (%Ls)',
|
2012-08-07 18:02:05 -07:00
|
|
|
$this->memberPHIDs);
|
|
|
|
}
|
|
|
|
|
2013-03-08 07:12:24 -08:00
|
|
|
if ($this->slugs) {
|
|
|
|
$where[] = qsprintf(
|
|
|
|
$conn_r,
|
2014-05-22 11:19:03 -07:00
|
|
|
'slug.slug IN (%Ls)',
|
2013-03-08 07:12:24 -08:00
|
|
|
$this->slugs);
|
|
|
|
}
|
|
|
|
|
2014-05-22 11:19:03 -07:00
|
|
|
if ($this->phrictionSlugs) {
|
|
|
|
$where[] = qsprintf(
|
|
|
|
$conn_r,
|
|
|
|
'phrictionSlug IN (%Ls)',
|
|
|
|
$this->phrictionSlugs);
|
|
|
|
}
|
|
|
|
|
2013-10-25 10:16:39 -07:00
|
|
|
if ($this->names) {
|
|
|
|
$where[] = qsprintf(
|
|
|
|
$conn_r,
|
|
|
|
'name IN (%Ls)',
|
|
|
|
$this->names);
|
|
|
|
}
|
|
|
|
|
2012-08-08 17:10:10 -07:00
|
|
|
$where[] = $this->buildPagingClause($conn_r);
|
|
|
|
|
2012-08-07 11:54:39 -07:00
|
|
|
return $this->formatWhereClause($where);
|
2011-12-16 17:08:18 -08:00
|
|
|
}
|
|
|
|
|
2012-08-07 18:02:05 -07:00
|
|
|
private function buildGroupClause($conn_r) {
|
2014-07-17 16:35:54 -07:00
|
|
|
if ($this->memberPHIDs || $this->datasourceQuery) {
|
2012-08-07 18:02:05 -07:00
|
|
|
return 'GROUP BY p.id';
|
|
|
|
} else {
|
2014-02-10 14:31:34 -08:00
|
|
|
return $this->buildApplicationSearchGroupClause($conn_r);
|
2012-08-07 18:02:05 -07:00
|
|
|
}
|
|
|
|
}
|
2011-12-16 17:08:18 -08:00
|
|
|
|
2012-08-07 18:02:05 -07:00
|
|
|
private function buildJoinClause($conn_r) {
|
2011-12-16 17:08:18 -08:00
|
|
|
$joins = array();
|
2012-08-07 18:02:05 -07:00
|
|
|
|
2014-07-17 16:35:54 -07:00
|
|
|
if (!$this->needMembers !== null) {
|
2012-08-11 07:05:01 -07:00
|
|
|
$joins[] = qsprintf(
|
|
|
|
$conn_r,
|
|
|
|
'LEFT JOIN %T vm ON vm.src = p.phid AND vm.type = %d AND vm.dst = %s',
|
|
|
|
PhabricatorEdgeConfig::TABLE_NAME_EDGE,
|
|
|
|
PhabricatorEdgeConfig::TYPE_PROJ_MEMBER,
|
|
|
|
$this->getViewer()->getPHID());
|
|
|
|
}
|
|
|
|
|
2014-07-17 16:35:54 -07:00
|
|
|
if ($this->memberPHIDs !== null) {
|
2011-12-16 17:08:18 -08:00
|
|
|
$joins[] = qsprintf(
|
|
|
|
$conn_r,
|
2012-08-11 07:05:01 -07:00
|
|
|
'JOIN %T e ON e.src = p.phid AND e.type = %d',
|
|
|
|
PhabricatorEdgeConfig::TABLE_NAME_EDGE,
|
|
|
|
PhabricatorEdgeConfig::TYPE_PROJ_MEMBER);
|
2011-12-16 17:08:18 -08:00
|
|
|
}
|
|
|
|
|
2014-07-17 16:35:54 -07:00
|
|
|
if ($this->slugs !== null) {
|
2014-05-22 11:19:03 -07:00
|
|
|
$joins[] = qsprintf(
|
|
|
|
$conn_r,
|
|
|
|
'JOIN %T slug on slug.projectPHID = p.phid',
|
|
|
|
id(new PhabricatorProjectSlug())->getTableName());
|
|
|
|
}
|
|
|
|
|
2014-07-17 16:35:54 -07:00
|
|
|
if ($this->datasourceQuery !== null) {
|
|
|
|
$tokens = PhabricatorTypeaheadDatasource::tokenizeString(
|
|
|
|
$this->datasourceQuery);
|
|
|
|
if (!$tokens) {
|
|
|
|
throw new PhabricatorEmptyQueryException();
|
|
|
|
}
|
|
|
|
|
|
|
|
$likes = array();
|
|
|
|
foreach ($tokens as $token) {
|
|
|
|
$likes[] = qsprintf($conn_r, 'token.token LIKE %>', $token);
|
|
|
|
}
|
|
|
|
|
|
|
|
$joins[] = qsprintf(
|
|
|
|
$conn_r,
|
|
|
|
'JOIN %T token ON token.projectID = p.id AND (%Q)',
|
|
|
|
PhabricatorProject::TABLE_DATASOURCE_TOKEN,
|
|
|
|
'('.implode(') OR (', $likes).')');
|
|
|
|
}
|
|
|
|
|
2014-02-10 14:31:34 -08:00
|
|
|
$joins[] = $this->buildApplicationSearchJoinClause($conn_r);
|
|
|
|
|
2011-12-16 17:08:18 -08:00
|
|
|
return implode(' ', $joins);
|
|
|
|
}
|
|
|
|
|
Lock policy queries to their applications
Summary:
While we mostly have reasonable effective object accessibility when you lock a user out of an application, it's primarily enforced at the controller level. Users can still, e.g., load the handles of objects they can't actually see. Instead, lock the queries to the applications so that you can, e.g., never load a revision if you don't have access to Differential.
This has several parts:
- For PolicyAware queries, provide an application class name method.
- If the query specifies a class name and the user doesn't have permission to use it, fail the entire query unconditionally.
- For handles, simplify query construction and count all the PHIDs as "restricted" so we get a UI full of "restricted" instead of "unknown" handles.
Test Plan:
- Added a unit test to verify I got all the class names right.
- Browsed around, logged in/out as a normal user with public policies on and off.
- Browsed around, logged in/out as a restricted user with public policies on and off. With restrictions, saw all traces of restricted apps removed or restricted.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Differential Revision: https://secure.phabricator.com/D7367
2013-10-21 17:20:27 -07:00
|
|
|
public function getQueryApplicationClass() {
|
2014-07-23 10:03:09 +10:00
|
|
|
return 'PhabricatorProjectApplication';
|
Lock policy queries to their applications
Summary:
While we mostly have reasonable effective object accessibility when you lock a user out of an application, it's primarily enforced at the controller level. Users can still, e.g., load the handles of objects they can't actually see. Instead, lock the queries to the applications so that you can, e.g., never load a revision if you don't have access to Differential.
This has several parts:
- For PolicyAware queries, provide an application class name method.
- If the query specifies a class name and the user doesn't have permission to use it, fail the entire query unconditionally.
- For handles, simplify query construction and count all the PHIDs as "restricted" so we get a UI full of "restricted" instead of "unknown" handles.
Test Plan:
- Added a unit test to verify I got all the class names right.
- Browsed around, logged in/out as a normal user with public policies on and off.
- Browsed around, logged in/out as a restricted user with public policies on and off. With restrictions, saw all traces of restricted apps removed or restricted.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Differential Revision: https://secure.phabricator.com/D7367
2013-10-21 17:20:27 -07:00
|
|
|
}
|
|
|
|
|
2014-02-10 14:31:34 -08:00
|
|
|
protected function getApplicationSearchObjectPHIDColumn() {
|
|
|
|
return 'p.phid';
|
|
|
|
}
|
|
|
|
|
2011-12-16 17:08:18 -08:00
|
|
|
}
|