2011-07-05 08:35:18 -07:00
|
|
|
<?php
|
|
|
|
|
|
2012-09-13 10:15:08 -07:00
|
|
|
final class PhabricatorFeedQuery
|
|
|
|
|
extends PhabricatorCursorPagedPolicyAwareQuery {
|
2011-07-05 08:35:18 -07:00
|
|
|
|
|
|
|
|
private $filterPHIDs;
|
2013-06-25 16:29:47 -07:00
|
|
|
private $chronologicalKeys;
|
2017-05-26 10:22:29 -07:00
|
|
|
private $rangeMin;
|
|
|
|
|
private $rangeMax;
|
2011-07-05 08:35:18 -07:00
|
|
|
|
2017-05-26 09:43:40 -07:00
|
|
|
public function withFilterPHIDs(array $phids) {
|
2011-07-05 08:35:18 -07:00
|
|
|
$this->filterPHIDs = $phids;
|
|
|
|
|
return $this;
|
|
|
|
|
}
|
|
|
|
|
|
2013-06-25 16:29:47 -07:00
|
|
|
public function withChronologicalKeys(array $keys) {
|
|
|
|
|
$this->chronologicalKeys = $keys;
|
|
|
|
|
return $this;
|
|
|
|
|
}
|
|
|
|
|
|
2017-05-26 10:22:29 -07:00
|
|
|
public function withEpochInRange($range_min, $range_max) {
|
|
|
|
|
$this->rangeMin = $range_min;
|
|
|
|
|
$this->rangeMax = $range_max;
|
|
|
|
|
return $this;
|
|
|
|
|
}
|
|
|
|
|
|
2017-05-26 09:43:40 -07:00
|
|
|
public function newResultObject() {
|
|
|
|
|
return new PhabricatorFeedStoryData();
|
|
|
|
|
}
|
2011-07-05 08:35:18 -07:00
|
|
|
|
2017-05-26 09:43:40 -07:00
|
|
|
protected function loadPage() {
|
|
|
|
|
// NOTE: We return raw rows from this method, which is a little unusual.
|
|
|
|
|
return $this->loadStandardPageRows($this->newResultObject());
|
Allow policy-aware queries to prefilter results
Summary:
Provides a simple way for policy-aware queries to pre-filter results without needing to maintain separate cursors, and fixes a bunch of filter-related edge cases.
- For reverse-paged cursor queries, we previously reversed each individual set of results. If the final result set is built out of multiple pages, it's in the wrong order overall, with each page in the correct order in sequence. Instead, reverse everything at the end. This also simplifies construction of queries.
- `AphrontCursorPagerView` would always render a "<< First" link when paging backward, even if we were on the first page of results.
- Add a filtering hook to let queries perform in-application pre-policy filtering as simply as possible (i.e., without maintaing their own cursors over the result sets).
Test Plan: Made feed randomly prefilter half the results, and paged forward and backward. Observed correct result ordering, pagination, and next/previous links.
Reviewers: btrahan, vrana
Reviewed By: btrahan
CC: aran
Differential Revision: https://secure.phabricator.com/D3787
2012-10-23 12:01:11 -07:00
|
|
|
}
|
2012-07-02 15:41:19 -07:00
|
|
|
|
Allow policy-aware queries to prefilter results
Summary:
Provides a simple way for policy-aware queries to pre-filter results without needing to maintain separate cursors, and fixes a bunch of filter-related edge cases.
- For reverse-paged cursor queries, we previously reversed each individual set of results. If the final result set is built out of multiple pages, it's in the wrong order overall, with each page in the correct order in sequence. Instead, reverse everything at the end. This also simplifies construction of queries.
- `AphrontCursorPagerView` would always render a "<< First" link when paging backward, even if we were on the first page of results.
- Add a filtering hook to let queries perform in-application pre-policy filtering as simply as possible (i.e., without maintaing their own cursors over the result sets).
Test Plan: Made feed randomly prefilter half the results, and paged forward and backward. Observed correct result ordering, pagination, and next/previous links.
Reviewers: btrahan, vrana
Reviewed By: btrahan
CC: aran
Differential Revision: https://secure.phabricator.com/D3787
2012-10-23 12:01:11 -07:00
|
|
|
protected function willFilterPage(array $data) {
|
2012-10-23 12:01:59 -07:00
|
|
|
return PhabricatorFeedStory::loadAllFromRows($data, $this->getViewer());
|
2012-02-15 17:48:14 -08:00
|
|
|
}
|
|
|
|
|
|
2017-05-26 09:43:40 -07:00
|
|
|
protected function buildJoinClauseParts(AphrontDatabaseConnection $conn) {
|
|
|
|
|
$joins = parent::buildJoinClauseParts($conn);
|
|
|
|
|
|
2012-07-02 15:41:19 -07:00
|
|
|
// NOTE: We perform this join unconditionally (even if we have no filter
|
|
|
|
|
// PHIDs) to omit rows which have no story references. These story data
|
|
|
|
|
// rows are notifications or realtime alerts.
|
2011-07-05 08:35:18 -07:00
|
|
|
|
|
|
|
|
$ref_table = new PhabricatorFeedStoryReference();
|
2017-05-26 09:43:40 -07:00
|
|
|
$joins[] = qsprintf(
|
|
|
|
|
$conn,
|
2012-07-02 15:41:19 -07:00
|
|
|
'JOIN %T ref ON ref.chronologicalKey = story.chronologicalKey',
|
|
|
|
|
$ref_table->getTableName());
|
2017-05-26 09:43:40 -07:00
|
|
|
|
|
|
|
|
return $joins;
|
2012-07-02 15:41:19 -07:00
|
|
|
}
|
2011-07-05 08:35:18 -07:00
|
|
|
|
2017-05-26 09:43:40 -07:00
|
|
|
protected function buildWhereClauseParts(AphrontDatabaseConnection $conn) {
|
|
|
|
|
$where = parent::buildWhereClauseParts($conn);
|
2012-07-02 15:41:19 -07:00
|
|
|
|
2017-05-26 09:43:40 -07:00
|
|
|
if ($this->filterPHIDs !== null) {
|
2011-07-05 08:35:18 -07:00
|
|
|
$where[] = qsprintf(
|
2017-05-26 09:43:40 -07:00
|
|
|
$conn,
|
2011-07-05 08:35:18 -07:00
|
|
|
'ref.objectPHID IN (%Ls)',
|
|
|
|
|
$this->filterPHIDs);
|
|
|
|
|
}
|
|
|
|
|
|
2017-05-26 09:43:40 -07:00
|
|
|
if ($this->chronologicalKeys !== null) {
|
2013-06-25 16:29:47 -07:00
|
|
|
// NOTE: We want to use integers in the query so we can take advantage
|
|
|
|
|
// of keys, but can't use %d on 32-bit systems. Make sure all the keys
|
|
|
|
|
// are integers and then format them raw.
|
|
|
|
|
|
|
|
|
|
$keys = $this->chronologicalKeys;
|
|
|
|
|
foreach ($keys as $key) {
|
|
|
|
|
if (!ctype_digit($key)) {
|
2015-05-22 17:27:56 +10:00
|
|
|
throw new Exception(
|
|
|
|
|
pht("Key '%s' is not a valid chronological key!", $key));
|
2013-06-25 16:29:47 -07:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
$where[] = qsprintf(
|
2017-05-26 09:43:40 -07:00
|
|
|
$conn,
|
2013-06-25 16:29:47 -07:00
|
|
|
'ref.chronologicalKey IN (%Q)',
|
|
|
|
|
implode(', ', $keys));
|
|
|
|
|
}
|
|
|
|
|
|
2017-05-26 10:22:29 -07:00
|
|
|
// NOTE: We may not have 64-bit PHP, so do the shifts in MySQL instead.
|
|
|
|
|
// From EXPLAIN, it appears like MySQL is smart enough to compute the
|
|
|
|
|
// result and make use of keys to execute the query.
|
|
|
|
|
|
|
|
|
|
if ($this->rangeMin !== null) {
|
|
|
|
|
$where[] = qsprintf(
|
|
|
|
|
$conn,
|
|
|
|
|
'ref.chronologicalKey >= (%d << 32)',
|
|
|
|
|
$this->rangeMin);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if ($this->rangeMax !== null) {
|
|
|
|
|
$where[] = qsprintf(
|
|
|
|
|
$conn,
|
|
|
|
|
'ref.chronologicalKey < (%d << 32)',
|
|
|
|
|
$this->rangeMax);
|
|
|
|
|
}
|
|
|
|
|
|
2017-05-26 09:43:40 -07:00
|
|
|
return $where;
|
2012-07-02 15:41:19 -07:00
|
|
|
}
|
2012-02-15 17:48:14 -08:00
|
|
|
|
2017-05-26 09:43:40 -07:00
|
|
|
protected function buildGroupClause(AphrontDatabaseConnection $conn) {
|
|
|
|
|
if ($this->filterPHIDs !== null) {
|
|
|
|
|
return qsprintf($conn, 'GROUP BY ref.chronologicalKey');
|
2015-03-17 22:19:02 +11:00
|
|
|
} else {
|
2017-05-26 09:43:40 -07:00
|
|
|
return qsprintf($conn, 'GROUP BY story.chronologicalKey');
|
2015-03-17 22:19:02 +11:00
|
|
|
}
|
2012-07-02 15:41:19 -07:00
|
|
|
}
|
2011-07-05 08:35:18 -07:00
|
|
|
|
2015-04-11 19:38:03 -07:00
|
|
|
protected function getDefaultOrderVector() {
|
|
|
|
|
return array('key');
|
|
|
|
|
}
|
|
|
|
|
|
2017-05-26 10:08:33 -07:00
|
|
|
public function getBuiltinOrders() {
|
|
|
|
|
return array(
|
|
|
|
|
'newest' => array(
|
|
|
|
|
'vector' => array('key'),
|
|
|
|
|
'name' => pht('Creation (Newest First)'),
|
|
|
|
|
'aliases' => array('created'),
|
|
|
|
|
),
|
|
|
|
|
'oldest' => array(
|
|
|
|
|
'vector' => array('-key'),
|
|
|
|
|
'name' => pht('Creation (Oldest First)'),
|
|
|
|
|
),
|
|
|
|
|
);
|
|
|
|
|
}
|
|
|
|
|
|
2015-04-11 19:38:03 -07:00
|
|
|
public function getOrderableColumns() {
|
|
|
|
|
$table = ($this->filterPHIDs ? 'ref' : 'story');
|
|
|
|
|
return array(
|
|
|
|
|
'key' => array(
|
|
|
|
|
'table' => $table,
|
|
|
|
|
'column' => 'chronologicalKey',
|
2015-06-11 10:23:20 -07:00
|
|
|
'type' => 'string',
|
2015-04-11 19:38:03 -07:00
|
|
|
'unique' => true,
|
|
|
|
|
),
|
|
|
|
|
);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
protected function getPagingValueMap($cursor, array $keys) {
|
|
|
|
|
return array(
|
|
|
|
|
'key' => $cursor,
|
|
|
|
|
);
|
2012-07-02 15:41:19 -07:00
|
|
|
}
|
2012-02-15 17:48:14 -08:00
|
|
|
|
2015-04-12 16:44:15 -07:00
|
|
|
protected function getResultCursor($item) {
|
Allow policy-aware queries to prefilter results
Summary:
Provides a simple way for policy-aware queries to pre-filter results without needing to maintain separate cursors, and fixes a bunch of filter-related edge cases.
- For reverse-paged cursor queries, we previously reversed each individual set of results. If the final result set is built out of multiple pages, it's in the wrong order overall, with each page in the correct order in sequence. Instead, reverse everything at the end. This also simplifies construction of queries.
- `AphrontCursorPagerView` would always render a "<< First" link when paging backward, even if we were on the first page of results.
- Add a filtering hook to let queries perform in-application pre-policy filtering as simply as possible (i.e., without maintaing their own cursors over the result sets).
Test Plan: Made feed randomly prefilter half the results, and paged forward and backward. Observed correct result ordering, pagination, and next/previous links.
Reviewers: btrahan, vrana
Reviewed By: btrahan
CC: aran
Differential Revision: https://secure.phabricator.com/D3787
2012-10-23 12:01:11 -07:00
|
|
|
if ($item instanceof PhabricatorFeedStory) {
|
|
|
|
|
return $item->getChronologicalKey();
|
|
|
|
|
}
|
|
|
|
|
return $item['chronologicalKey'];
|
2011-07-05 08:35:18 -07:00
|
|
|
}
|
2012-07-02 10:37:22 -07:00
|
|
|
|
2017-05-26 09:43:40 -07:00
|
|
|
protected function getPrimaryTableAlias() {
|
|
|
|
|
return 'story';
|
|
|
|
|
}
|
|
|
|
|
|
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 'PhabricatorFeedApplication';
|
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
|
|
|
}
|
|
|
|
|
|
2011-07-05 08:35:18 -07:00
|
|
|
}
|