2012-06-08 15:31:30 +02:00
|
|
|
<?php
|
|
|
|
|
2012-06-28 22:59:50 +02:00
|
|
|
/**
|
|
|
|
* @task config Configuring the Query
|
|
|
|
* @task exec Query Execution
|
|
|
|
*/
|
2012-10-23 21:01:59 +02:00
|
|
|
final class PhabricatorNotificationQuery
|
|
|
|
extends PhabricatorCursorPagedPolicyAwareQuery {
|
2012-06-08 15:31:30 +02:00
|
|
|
|
2014-08-16 20:14:32 +02:00
|
|
|
private $userPHIDs;
|
2012-06-18 23:08:10 +02:00
|
|
|
private $keys;
|
2012-06-28 22:59:50 +02:00
|
|
|
private $unread;
|
|
|
|
|
|
|
|
|
|
|
|
/* -( Configuring the Query )---------------------------------------------- */
|
|
|
|
|
2012-06-08 15:31:30 +02:00
|
|
|
|
2014-08-16 20:14:32 +02:00
|
|
|
public function withUserPHIDs(array $user_phids) {
|
|
|
|
$this->userPHIDs = $user_phids;
|
2012-06-08 15:31:30 +02:00
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
2012-06-18 23:08:10 +02:00
|
|
|
public function withKeys(array $keys) {
|
|
|
|
$this->keys = $keys;
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
2012-06-28 22:59:50 +02:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Filter results by read/unread status. Note that `true` means to return
|
|
|
|
* only unread notifications, while `false` means to return only //read//
|
|
|
|
* notifications. The default is `null`, which returns both.
|
|
|
|
*
|
|
|
|
* @param mixed True or false to filter results by read status. Null to remove
|
|
|
|
* the filter.
|
|
|
|
* @return this
|
|
|
|
* @task config
|
|
|
|
*/
|
|
|
|
public function withUnread($unread) {
|
|
|
|
$this->unread = $unread;
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/* -( Query Execution )---------------------------------------------------- */
|
|
|
|
|
|
|
|
|
2013-03-01 20:28:02 +01:00
|
|
|
protected function loadPage() {
|
2012-06-08 15:31:30 +02:00
|
|
|
$story_table = new PhabricatorFeedStoryData();
|
|
|
|
$notification_table = new PhabricatorFeedStoryNotification();
|
|
|
|
|
|
|
|
$conn = $story_table->establishConnection('r');
|
|
|
|
|
|
|
|
$data = queryfx_all(
|
|
|
|
$conn,
|
2019-04-22 16:22:00 +02:00
|
|
|
'SELECT story.*, notification.hasViewed FROM %R notification
|
|
|
|
JOIN %R story ON notification.chronologicalKey = story.chronologicalKey
|
2012-06-18 23:08:10 +02:00
|
|
|
%Q
|
2019-04-22 16:22:00 +02:00
|
|
|
ORDER BY notification.chronologicalKey DESC
|
2014-06-09 20:36:49 +02:00
|
|
|
%Q',
|
Separate "feed" and "notifications" better, allow stories to appear in notifications only
Summary:
Depends on D19861. Ref T13222. See PHI996. Fixes T10743. Currently, notifications only work if a story also has a feed rendering.
Separate "visible in feed" and "visible in notifications", and make notifications query only notifications and vice versa.
Then, set the test notification stories to be visible in notifications only, not feed.
This could be refined a bit (there's no way to have the two views render different values today, for example) but since the only actual use case we have right now is test notifications I don't want to go //too// crazy future-proofing it. I could imagine doing some more of this kind of stuff in Conpherence eventually, though, perhaps.
Test Plan: Sent myself test notifications, saw them appear on my profile timeline and in the JS popup, and in my notifications menu, but not in feed.
Reviewers: amckinley
Reviewed By: amckinley
Maniphest Tasks: T13222, T10743
Differential Revision: https://secure.phabricator.com/D19864
2018-12-10 21:40:24 +01:00
|
|
|
$notification_table,
|
|
|
|
$story_table,
|
2012-06-18 23:08:10 +02:00
|
|
|
$this->buildWhereClause($conn),
|
2012-06-18 23:07:38 +02:00
|
|
|
$this->buildLimitClause($conn));
|
2012-06-08 15:31:30 +02:00
|
|
|
|
|
|
|
$viewed_map = ipull($data, 'hasViewed', 'chronologicalKey');
|
2012-06-18 23:08:10 +02:00
|
|
|
|
2012-10-23 21:01:59 +02:00
|
|
|
$stories = PhabricatorFeedStory::loadAllFromRows(
|
|
|
|
$data,
|
|
|
|
$this->getViewer());
|
|
|
|
|
2012-07-02 19:37:22 +02:00
|
|
|
foreach ($stories as $key => $story) {
|
|
|
|
$story->setHasViewed($viewed_map[$key]);
|
2012-06-08 15:31:30 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
return $stories;
|
|
|
|
}
|
2012-06-18 23:08:10 +02:00
|
|
|
|
Fix the most significant "phantom notification" badness
Summary:
Ref T13124. Ref T13131. Fixes T8953. See PHI512.
When you receieve a notification about an object and then someone hides that object from you (or deletes it), you get a phantom notification which is very difficult to clear.
For now, test that notifications are visible when you open the menu and clear any that are not.
This could be a little more elegant than it is, but the current behavior is very clearly broken. This unbreaks it, at least.
Test Plan:
- As Alice, configured task stuff to notify me (instead of sending email).
- As Bailey, added Alice as a subscriber to a task, then commented on it.
- As Alice, loaded home and saw a notification count. Didn't click it yet.
- As Bailey, set the task to private.
- As Alice, clicked the notification bell menu icon.
- Before change: no unread notifications, bell menu is semi-stuck in a phantom state which you can't clear.
- After change: bad notifications automatically cleared.
{F5530005}
Reviewers: amckinley
Reviewed By: amckinley
Maniphest Tasks: T13131, T13124, T8953
Differential Revision: https://secure.phabricator.com/D19384
2018-04-19 19:49:30 +02:00
|
|
|
protected function buildWhereClauseParts(AphrontDatabaseConnection $conn) {
|
|
|
|
$where = parent::buildWhereClauseParts($conn);
|
2012-06-18 23:08:10 +02:00
|
|
|
|
2014-08-16 20:14:32 +02:00
|
|
|
if ($this->userPHIDs !== null) {
|
2012-06-18 23:08:10 +02:00
|
|
|
$where[] = qsprintf(
|
Fix the most significant "phantom notification" badness
Summary:
Ref T13124. Ref T13131. Fixes T8953. See PHI512.
When you receieve a notification about an object and then someone hides that object from you (or deletes it), you get a phantom notification which is very difficult to clear.
For now, test that notifications are visible when you open the menu and clear any that are not.
This could be a little more elegant than it is, but the current behavior is very clearly broken. This unbreaks it, at least.
Test Plan:
- As Alice, configured task stuff to notify me (instead of sending email).
- As Bailey, added Alice as a subscriber to a task, then commented on it.
- As Alice, loaded home and saw a notification count. Didn't click it yet.
- As Bailey, set the task to private.
- As Alice, clicked the notification bell menu icon.
- Before change: no unread notifications, bell menu is semi-stuck in a phantom state which you can't clear.
- After change: bad notifications automatically cleared.
{F5530005}
Reviewers: amckinley
Reviewed By: amckinley
Maniphest Tasks: T13131, T13124, T8953
Differential Revision: https://secure.phabricator.com/D19384
2018-04-19 19:49:30 +02:00
|
|
|
$conn,
|
2019-04-22 16:22:00 +02:00
|
|
|
'notification.userPHID IN (%Ls)',
|
2014-08-16 20:14:32 +02:00
|
|
|
$this->userPHIDs);
|
2012-06-18 23:08:10 +02:00
|
|
|
}
|
|
|
|
|
2012-06-28 22:59:50 +02:00
|
|
|
if ($this->unread !== null) {
|
|
|
|
$where[] = qsprintf(
|
Fix the most significant "phantom notification" badness
Summary:
Ref T13124. Ref T13131. Fixes T8953. See PHI512.
When you receieve a notification about an object and then someone hides that object from you (or deletes it), you get a phantom notification which is very difficult to clear.
For now, test that notifications are visible when you open the menu and clear any that are not.
This could be a little more elegant than it is, but the current behavior is very clearly broken. This unbreaks it, at least.
Test Plan:
- As Alice, configured task stuff to notify me (instead of sending email).
- As Bailey, added Alice as a subscriber to a task, then commented on it.
- As Alice, loaded home and saw a notification count. Didn't click it yet.
- As Bailey, set the task to private.
- As Alice, clicked the notification bell menu icon.
- Before change: no unread notifications, bell menu is semi-stuck in a phantom state which you can't clear.
- After change: bad notifications automatically cleared.
{F5530005}
Reviewers: amckinley
Reviewed By: amckinley
Maniphest Tasks: T13131, T13124, T8953
Differential Revision: https://secure.phabricator.com/D19384
2018-04-19 19:49:30 +02:00
|
|
|
$conn,
|
2019-04-22 16:22:00 +02:00
|
|
|
'notification.hasViewed = %d',
|
2012-06-28 22:59:50 +02:00
|
|
|
(int)!$this->unread);
|
|
|
|
}
|
|
|
|
|
Separate "feed" and "notifications" better, allow stories to appear in notifications only
Summary:
Depends on D19861. Ref T13222. See PHI996. Fixes T10743. Currently, notifications only work if a story also has a feed rendering.
Separate "visible in feed" and "visible in notifications", and make notifications query only notifications and vice versa.
Then, set the test notification stories to be visible in notifications only, not feed.
This could be refined a bit (there's no way to have the two views render different values today, for example) but since the only actual use case we have right now is test notifications I don't want to go //too// crazy future-proofing it. I could imagine doing some more of this kind of stuff in Conpherence eventually, though, perhaps.
Test Plan: Sent myself test notifications, saw them appear on my profile timeline and in the JS popup, and in my notifications menu, but not in feed.
Reviewers: amckinley
Reviewed By: amckinley
Maniphest Tasks: T13222, T10743
Differential Revision: https://secure.phabricator.com/D19864
2018-12-10 21:40:24 +01:00
|
|
|
if ($this->keys !== null) {
|
2012-06-18 23:08:10 +02:00
|
|
|
$where[] = qsprintf(
|
Fix the most significant "phantom notification" badness
Summary:
Ref T13124. Ref T13131. Fixes T8953. See PHI512.
When you receieve a notification about an object and then someone hides that object from you (or deletes it), you get a phantom notification which is very difficult to clear.
For now, test that notifications are visible when you open the menu and clear any that are not.
This could be a little more elegant than it is, but the current behavior is very clearly broken. This unbreaks it, at least.
Test Plan:
- As Alice, configured task stuff to notify me (instead of sending email).
- As Bailey, added Alice as a subscriber to a task, then commented on it.
- As Alice, loaded home and saw a notification count. Didn't click it yet.
- As Bailey, set the task to private.
- As Alice, clicked the notification bell menu icon.
- Before change: no unread notifications, bell menu is semi-stuck in a phantom state which you can't clear.
- After change: bad notifications automatically cleared.
{F5530005}
Reviewers: amckinley
Reviewed By: amckinley
Maniphest Tasks: T13131, T13124, T8953
Differential Revision: https://secure.phabricator.com/D19384
2018-04-19 19:49:30 +02:00
|
|
|
$conn,
|
2019-04-22 16:22:00 +02:00
|
|
|
'notification.chronologicalKey IN (%Ls)',
|
2012-06-18 23:08:10 +02:00
|
|
|
$this->keys);
|
|
|
|
}
|
|
|
|
|
Fix the most significant "phantom notification" badness
Summary:
Ref T13124. Ref T13131. Fixes T8953. See PHI512.
When you receieve a notification about an object and then someone hides that object from you (or deletes it), you get a phantom notification which is very difficult to clear.
For now, test that notifications are visible when you open the menu and clear any that are not.
This could be a little more elegant than it is, but the current behavior is very clearly broken. This unbreaks it, at least.
Test Plan:
- As Alice, configured task stuff to notify me (instead of sending email).
- As Bailey, added Alice as a subscriber to a task, then commented on it.
- As Alice, loaded home and saw a notification count. Didn't click it yet.
- As Bailey, set the task to private.
- As Alice, clicked the notification bell menu icon.
- Before change: no unread notifications, bell menu is semi-stuck in a phantom state which you can't clear.
- After change: bad notifications automatically cleared.
{F5530005}
Reviewers: amckinley
Reviewed By: amckinley
Maniphest Tasks: T13131, T13124, T8953
Differential Revision: https://secure.phabricator.com/D19384
2018-04-19 19:49:30 +02:00
|
|
|
return $where;
|
2012-06-18 23:08:10 +02:00
|
|
|
}
|
|
|
|
|
Separate "feed" and "notifications" better, allow stories to appear in notifications only
Summary:
Depends on D19861. Ref T13222. See PHI996. Fixes T10743. Currently, notifications only work if a story also has a feed rendering.
Separate "visible in feed" and "visible in notifications", and make notifications query only notifications and vice versa.
Then, set the test notification stories to be visible in notifications only, not feed.
This could be refined a bit (there's no way to have the two views render different values today, for example) but since the only actual use case we have right now is test notifications I don't want to go //too// crazy future-proofing it. I could imagine doing some more of this kind of stuff in Conpherence eventually, though, perhaps.
Test Plan: Sent myself test notifications, saw them appear on my profile timeline and in the JS popup, and in my notifications menu, but not in feed.
Reviewers: amckinley
Reviewed By: amckinley
Maniphest Tasks: T13222, T10743
Differential Revision: https://secure.phabricator.com/D19864
2018-12-10 21:40:24 +01:00
|
|
|
protected function willFilterPage(array $stories) {
|
|
|
|
foreach ($stories as $key => $story) {
|
|
|
|
if (!$story->isVisibleInNotifications()) {
|
|
|
|
unset($stories[$key]);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return $stories;
|
|
|
|
}
|
|
|
|
|
2019-04-22 16:22:00 +02:00
|
|
|
protected function getDefaultOrderVector() {
|
|
|
|
return array('key');
|
|
|
|
}
|
|
|
|
|
|
|
|
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)'),
|
|
|
|
),
|
|
|
|
);
|
|
|
|
}
|
|
|
|
|
|
|
|
public function getOrderableColumns() {
|
|
|
|
return array(
|
|
|
|
'key' => array(
|
|
|
|
'table' => 'notification',
|
|
|
|
'column' => 'chronologicalKey',
|
|
|
|
'type' => 'string',
|
|
|
|
'unique' => true,
|
|
|
|
),
|
|
|
|
);
|
|
|
|
}
|
|
|
|
|
|
|
|
protected function applyExternalCursorConstraintsToQuery(
|
|
|
|
PhabricatorCursorPagedPolicyAwareQuery $subquery,
|
|
|
|
$cursor) {
|
|
|
|
$subquery->withKeys(array($cursor));
|
|
|
|
}
|
|
|
|
|
|
|
|
protected function newExternalCursorStringForResult($object) {
|
|
|
|
return $object->getChronologicalKey();
|
|
|
|
}
|
|
|
|
|
|
|
|
protected function newPagingMapFromPartialObject($object) {
|
|
|
|
return array(
|
|
|
|
'key' => $object->getChronologicalKey(),
|
|
|
|
);
|
|
|
|
}
|
|
|
|
|
|
|
|
protected function getPrimaryTableAlias() {
|
|
|
|
return 'notification';
|
2013-10-05 04:57:15 +02:00
|
|
|
}
|
|
|
|
|
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-22 02:20:27 +02:00
|
|
|
public function getQueryApplicationClass() {
|
2014-07-23 02:03:09 +02:00
|
|
|
return 'PhabricatorNotificationsApplication';
|
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-22 02:20:27 +02:00
|
|
|
}
|
|
|
|
|
2012-06-08 15:31:30 +02:00
|
|
|
}
|