2014-02-06 19:10:27 +01:00
|
|
|
<?php
|
|
|
|
|
|
|
|
final class PhabricatorCalendarEventViewController
|
2014-02-18 01:08:50 +01:00
|
|
|
extends PhabricatorCalendarController {
|
2014-02-06 19:10:27 +01:00
|
|
|
|
2014-05-14 19:00:46 +02:00
|
|
|
public function shouldAllowPublic() {
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2015-08-02 00:43:14 +02:00
|
|
|
public function handleRequest(AphrontRequest $request) {
|
|
|
|
$viewer = $request->getViewer();
|
2015-05-29 02:27:25 +02:00
|
|
|
|
Generate "stub" events earlier, so more infrastructure works with Calendar
Summary:
Ref T9275. When you create a recurring event which recurs forever, we want to avoid writing an infinite number of rows to the database.
Currently, we write a row to the database right before you edit the event. Until then, we refer to it as `E123/999` or whatever ("instance 999 of event 123").
This creates a big mess with trying to make recurring events work with EditEngine, Subscriptions, Projects, Flags, Tokens, etc -- all of this stuff assumes that whatever you're working with has a PHID.
I poked at letting this stuff work without a PHID a little bit, but that looked like a gigantic mess.
Instead, generate an event "stub" a little sooner (when you look at the event detail page). This is basically just an ID/PHID to refer to the instance.
Then, when you edit the stub, "materialize" it into a real event.
This still has some issues, but I think it's more promising than the other approach was.
Also:
- Removes dead user profile calendar controller.
- Replaces comments with EditEngine comments.
Test Plan:
- Commented on a recurring event.
- Awarded tokens to a recurring event.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T9275
Differential Revision: https://secure.phabricator.com/D16248
2016-07-07 16:19:58 +02:00
|
|
|
$event = $this->loadEvent();
|
2014-02-06 19:10:27 +01:00
|
|
|
if (!$event) {
|
|
|
|
return new Aphront404Response();
|
|
|
|
}
|
|
|
|
|
Generate "stub" events earlier, so more infrastructure works with Calendar
Summary:
Ref T9275. When you create a recurring event which recurs forever, we want to avoid writing an infinite number of rows to the database.
Currently, we write a row to the database right before you edit the event. Until then, we refer to it as `E123/999` or whatever ("instance 999 of event 123").
This creates a big mess with trying to make recurring events work with EditEngine, Subscriptions, Projects, Flags, Tokens, etc -- all of this stuff assumes that whatever you're working with has a PHID.
I poked at letting this stuff work without a PHID a little bit, but that looked like a gigantic mess.
Instead, generate an event "stub" a little sooner (when you look at the event detail page). This is basically just an ID/PHID to refer to the instance.
Then, when you edit the stub, "materialize" it into a real event.
This still has some issues, but I think it's more promising than the other approach was.
Also:
- Removes dead user profile calendar controller.
- Replaces comments with EditEngine comments.
Test Plan:
- Commented on a recurring event.
- Awarded tokens to a recurring event.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T9275
Differential Revision: https://secure.phabricator.com/D16248
2016-07-07 16:19:58 +02:00
|
|
|
// If we looked up or generated a stub event, redirect to that event's
|
|
|
|
// canonical URI.
|
|
|
|
$id = $request->getURIData('id');
|
|
|
|
if ($event->getID() != $id) {
|
|
|
|
$uri = $event->getURI();
|
|
|
|
return id(new AphrontRedirectResponse())->setURI($uri);
|
2015-06-08 20:05:54 +02:00
|
|
|
}
|
2014-02-06 19:10:27 +01:00
|
|
|
|
Generate "stub" events earlier, so more infrastructure works with Calendar
Summary:
Ref T9275. When you create a recurring event which recurs forever, we want to avoid writing an infinite number of rows to the database.
Currently, we write a row to the database right before you edit the event. Until then, we refer to it as `E123/999` or whatever ("instance 999 of event 123").
This creates a big mess with trying to make recurring events work with EditEngine, Subscriptions, Projects, Flags, Tokens, etc -- all of this stuff assumes that whatever you're working with has a PHID.
I poked at letting this stuff work without a PHID a little bit, but that looked like a gigantic mess.
Instead, generate an event "stub" a little sooner (when you look at the event detail page). This is basically just an ID/PHID to refer to the instance.
Then, when you edit the stub, "materialize" it into a real event.
This still has some issues, but I think it's more promising than the other approach was.
Also:
- Removes dead user profile calendar controller.
- Replaces comments with EditEngine comments.
Test Plan:
- Commented on a recurring event.
- Awarded tokens to a recurring event.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T9275
Differential Revision: https://secure.phabricator.com/D16248
2016-07-07 16:19:58 +02:00
|
|
|
$monogram = $event->getMonogram();
|
|
|
|
$page_title = $monogram.' '.$event->getName();
|
|
|
|
$crumbs = $this->buildApplicationCrumbs();
|
|
|
|
$crumbs->addTextCrumb($monogram);
|
|
|
|
$crumbs->setBorder(true);
|
|
|
|
|
|
|
|
$timeline = $this->buildTransactionTimeline(
|
|
|
|
$event,
|
|
|
|
new PhabricatorCalendarEventTransactionQuery());
|
2015-04-28 15:26:48 +02:00
|
|
|
|
2014-02-06 19:10:27 +01:00
|
|
|
$header = $this->buildHeaderView($event);
|
2016-03-06 19:08:49 +01:00
|
|
|
$curtain = $this->buildCurtain($event);
|
2016-03-03 03:09:13 +01:00
|
|
|
$details = $this->buildPropertySection($event);
|
|
|
|
$description = $this->buildDescriptionView($event);
|
2014-02-06 19:10:27 +01:00
|
|
|
|
2016-07-13 17:39:42 +02:00
|
|
|
$comment_view = id(new PhabricatorCalendarEventEditEngine())
|
Generate "stub" events earlier, so more infrastructure works with Calendar
Summary:
Ref T9275. When you create a recurring event which recurs forever, we want to avoid writing an infinite number of rows to the database.
Currently, we write a row to the database right before you edit the event. Until then, we refer to it as `E123/999` or whatever ("instance 999 of event 123").
This creates a big mess with trying to make recurring events work with EditEngine, Subscriptions, Projects, Flags, Tokens, etc -- all of this stuff assumes that whatever you're working with has a PHID.
I poked at letting this stuff work without a PHID a little bit, but that looked like a gigantic mess.
Instead, generate an event "stub" a little sooner (when you look at the event detail page). This is basically just an ID/PHID to refer to the instance.
Then, when you edit the stub, "materialize" it into a real event.
This still has some issues, but I think it's more promising than the other approach was.
Also:
- Removes dead user profile calendar controller.
- Replaces comments with EditEngine comments.
Test Plan:
- Commented on a recurring event.
- Awarded tokens to a recurring event.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T9275
Differential Revision: https://secure.phabricator.com/D16248
2016-07-07 16:19:58 +02:00
|
|
|
->setViewer($viewer)
|
|
|
|
->buildEditEngineCommentView($event);
|
|
|
|
|
|
|
|
$timeline->setQuoteRef($monogram);
|
|
|
|
$comment_view->setTransactionTimeline($timeline);
|
2015-05-01 02:38:04 +02:00
|
|
|
|
2016-03-03 03:09:13 +01:00
|
|
|
$view = id(new PHUITwoColumnView())
|
|
|
|
->setHeader($header)
|
Generate "stub" events earlier, so more infrastructure works with Calendar
Summary:
Ref T9275. When you create a recurring event which recurs forever, we want to avoid writing an infinite number of rows to the database.
Currently, we write a row to the database right before you edit the event. Until then, we refer to it as `E123/999` or whatever ("instance 999 of event 123").
This creates a big mess with trying to make recurring events work with EditEngine, Subscriptions, Projects, Flags, Tokens, etc -- all of this stuff assumes that whatever you're working with has a PHID.
I poked at letting this stuff work without a PHID a little bit, but that looked like a gigantic mess.
Instead, generate an event "stub" a little sooner (when you look at the event detail page). This is basically just an ID/PHID to refer to the instance.
Then, when you edit the stub, "materialize" it into a real event.
This still has some issues, but I think it's more promising than the other approach was.
Also:
- Removes dead user profile calendar controller.
- Replaces comments with EditEngine comments.
Test Plan:
- Commented on a recurring event.
- Awarded tokens to a recurring event.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T9275
Differential Revision: https://secure.phabricator.com/D16248
2016-07-07 16:19:58 +02:00
|
|
|
->setMainColumn(
|
|
|
|
array(
|
2016-03-08 16:26:56 +01:00
|
|
|
$timeline,
|
Generate "stub" events earlier, so more infrastructure works with Calendar
Summary:
Ref T9275. When you create a recurring event which recurs forever, we want to avoid writing an infinite number of rows to the database.
Currently, we write a row to the database right before you edit the event. Until then, we refer to it as `E123/999` or whatever ("instance 999 of event 123").
This creates a big mess with trying to make recurring events work with EditEngine, Subscriptions, Projects, Flags, Tokens, etc -- all of this stuff assumes that whatever you're working with has a PHID.
I poked at letting this stuff work without a PHID a little bit, but that looked like a gigantic mess.
Instead, generate an event "stub" a little sooner (when you look at the event detail page). This is basically just an ID/PHID to refer to the instance.
Then, when you edit the stub, "materialize" it into a real event.
This still has some issues, but I think it's more promising than the other approach was.
Also:
- Removes dead user profile calendar controller.
- Replaces comments with EditEngine comments.
Test Plan:
- Commented on a recurring event.
- Awarded tokens to a recurring event.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T9275
Differential Revision: https://secure.phabricator.com/D16248
2016-07-07 16:19:58 +02:00
|
|
|
$comment_view,
|
2016-03-08 16:26:56 +01:00
|
|
|
))
|
2016-03-06 19:08:49 +01:00
|
|
|
->setCurtain($curtain)
|
2016-04-07 00:20:53 +02:00
|
|
|
->addPropertySection(pht('Details'), $details)
|
|
|
|
->addPropertySection(pht('Description'), $description);
|
2016-03-03 03:09:13 +01:00
|
|
|
|
|
|
|
return $this->newPage()
|
|
|
|
->setTitle($page_title)
|
|
|
|
->setCrumbs($crumbs)
|
|
|
|
->setPageObjectPHIDs(array($event->getPHID()))
|
Generate "stub" events earlier, so more infrastructure works with Calendar
Summary:
Ref T9275. When you create a recurring event which recurs forever, we want to avoid writing an infinite number of rows to the database.
Currently, we write a row to the database right before you edit the event. Until then, we refer to it as `E123/999` or whatever ("instance 999 of event 123").
This creates a big mess with trying to make recurring events work with EditEngine, Subscriptions, Projects, Flags, Tokens, etc -- all of this stuff assumes that whatever you're working with has a PHID.
I poked at letting this stuff work without a PHID a little bit, but that looked like a gigantic mess.
Instead, generate an event "stub" a little sooner (when you look at the event detail page). This is basically just an ID/PHID to refer to the instance.
Then, when you edit the stub, "materialize" it into a real event.
This still has some issues, but I think it's more promising than the other approach was.
Also:
- Removes dead user profile calendar controller.
- Replaces comments with EditEngine comments.
Test Plan:
- Commented on a recurring event.
- Awarded tokens to a recurring event.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T9275
Differential Revision: https://secure.phabricator.com/D16248
2016-07-07 16:19:58 +02:00
|
|
|
->appendChild($view);
|
2014-02-06 19:10:27 +01:00
|
|
|
}
|
|
|
|
|
2016-03-03 03:09:13 +01:00
|
|
|
private function buildHeaderView(
|
|
|
|
PhabricatorCalendarEvent $event) {
|
|
|
|
$viewer = $this->getViewer();
|
2015-04-30 04:48:46 +02:00
|
|
|
$id = $event->getID();
|
|
|
|
|
Canceling calendar events should deactivate the event
Summary: Closes T7943, Canceling calendar event should deactivate the event instead of destroying data.
Test Plan: Create an event, cancel it, see changed status icon, query for active events, event should not appear, query for deactivated events, event should appear in results.
Reviewers: #blessed_reviewers, epriestley
Reviewed By: #blessed_reviewers, epriestley
Subscribers: Korvin, epriestley
Maniphest Tasks: T7943
Differential Revision: https://secure.phabricator.com/D12604
2015-04-29 17:39:39 +02:00
|
|
|
$is_cancelled = $event->getIsCancelled();
|
2016-03-03 03:09:13 +01:00
|
|
|
$icon = $is_cancelled ? ('fa-ban') : ('fa-check');
|
|
|
|
$color = $is_cancelled ? ('red') : ('bluegrey');
|
2015-05-06 20:11:38 +02:00
|
|
|
$status = $is_cancelled ? pht('Cancelled') : pht('Active');
|
2014-02-06 19:10:27 +01:00
|
|
|
|
2015-04-30 04:48:46 +02:00
|
|
|
$invite_status = $event->getUserInviteStatus($viewer->getPHID());
|
|
|
|
$status_invited = PhabricatorCalendarEventInvitee::STATUS_INVITED;
|
|
|
|
$is_invite_pending = ($invite_status == $status_invited);
|
|
|
|
|
|
|
|
$header = id(new PHUIHeaderView())
|
2014-02-06 19:10:27 +01:00
|
|
|
->setUser($viewer)
|
2015-04-28 17:34:26 +02:00
|
|
|
->setHeader($event->getName())
|
Canceling calendar events should deactivate the event
Summary: Closes T7943, Canceling calendar event should deactivate the event instead of destroying data.
Test Plan: Create an event, cancel it, see changed status icon, query for active events, event should not appear, query for deactivated events, event should appear in results.
Reviewers: #blessed_reviewers, epriestley
Reviewed By: #blessed_reviewers, epriestley
Subscribers: Korvin, epriestley
Maniphest Tasks: T7943
Differential Revision: https://secure.phabricator.com/D12604
2015-04-29 17:39:39 +02:00
|
|
|
->setStatus($icon, $color, $status)
|
2016-03-03 03:09:13 +01:00
|
|
|
->setPolicyObject($event)
|
|
|
|
->setHeaderIcon('fa-calendar');
|
2015-04-30 04:48:46 +02:00
|
|
|
|
|
|
|
if ($is_invite_pending) {
|
|
|
|
$decline_button = id(new PHUIButtonView())
|
|
|
|
->setTag('a')
|
2016-01-28 05:38:01 +01:00
|
|
|
->setIcon('fa-times grey')
|
2015-04-30 04:48:46 +02:00
|
|
|
->setHref($this->getApplicationURI("/event/decline/{$id}/"))
|
|
|
|
->setWorkflow(true)
|
|
|
|
->setText(pht('Decline'));
|
|
|
|
|
|
|
|
$accept_button = id(new PHUIButtonView())
|
|
|
|
->setTag('a')
|
2016-01-28 05:38:01 +01:00
|
|
|
->setIcon('fa-check green')
|
2015-04-30 04:48:46 +02:00
|
|
|
->setHref($this->getApplicationURI("/event/accept/{$id}/"))
|
|
|
|
->setWorkflow(true)
|
|
|
|
->setText(pht('Accept'));
|
|
|
|
|
|
|
|
$header->addActionLink($decline_button)
|
|
|
|
->addActionLink($accept_button);
|
|
|
|
}
|
|
|
|
return $header;
|
2014-02-06 19:10:27 +01:00
|
|
|
}
|
|
|
|
|
2016-03-06 19:08:49 +01:00
|
|
|
private function buildCurtain(PhabricatorCalendarEvent $event) {
|
2014-02-06 19:10:27 +01:00
|
|
|
$viewer = $this->getRequest()->getUser();
|
|
|
|
$id = $event->getID();
|
Generate "stub" events earlier, so more infrastructure works with Calendar
Summary:
Ref T9275. When you create a recurring event which recurs forever, we want to avoid writing an infinite number of rows to the database.
Currently, we write a row to the database right before you edit the event. Until then, we refer to it as `E123/999` or whatever ("instance 999 of event 123").
This creates a big mess with trying to make recurring events work with EditEngine, Subscriptions, Projects, Flags, Tokens, etc -- all of this stuff assumes that whatever you're working with has a PHID.
I poked at letting this stuff work without a PHID a little bit, but that looked like a gigantic mess.
Instead, generate an event "stub" a little sooner (when you look at the event detail page). This is basically just an ID/PHID to refer to the instance.
Then, when you edit the stub, "materialize" it into a real event.
This still has some issues, but I think it's more promising than the other approach was.
Also:
- Removes dead user profile calendar controller.
- Replaces comments with EditEngine comments.
Test Plan:
- Commented on a recurring event.
- Awarded tokens to a recurring event.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T9275
Differential Revision: https://secure.phabricator.com/D16248
2016-07-07 16:19:58 +02:00
|
|
|
$is_cancelled = $event->isCancelledEvent();
|
2015-04-30 03:18:27 +02:00
|
|
|
$is_attending = $event->getIsUserAttending($viewer->getPHID());
|
2014-02-06 19:10:27 +01:00
|
|
|
|
|
|
|
$can_edit = PhabricatorPolicyFilter::hasCapability(
|
|
|
|
$viewer,
|
|
|
|
$event,
|
|
|
|
PhabricatorPolicyCapability::CAN_EDIT);
|
|
|
|
|
Generate "stub" events earlier, so more infrastructure works with Calendar
Summary:
Ref T9275. When you create a recurring event which recurs forever, we want to avoid writing an infinite number of rows to the database.
Currently, we write a row to the database right before you edit the event. Until then, we refer to it as `E123/999` or whatever ("instance 999 of event 123").
This creates a big mess with trying to make recurring events work with EditEngine, Subscriptions, Projects, Flags, Tokens, etc -- all of this stuff assumes that whatever you're working with has a PHID.
I poked at letting this stuff work without a PHID a little bit, but that looked like a gigantic mess.
Instead, generate an event "stub" a little sooner (when you look at the event detail page). This is basically just an ID/PHID to refer to the instance.
Then, when you edit the stub, "materialize" it into a real event.
This still has some issues, but I think it's more promising than the other approach was.
Also:
- Removes dead user profile calendar controller.
- Replaces comments with EditEngine comments.
Test Plan:
- Commented on a recurring event.
- Awarded tokens to a recurring event.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T9275
Differential Revision: https://secure.phabricator.com/D16248
2016-07-07 16:19:58 +02:00
|
|
|
$edit_uri = "event/edit/{$id}/";
|
|
|
|
if ($event->isChildEvent()) {
|
2015-06-02 16:29:48 +02:00
|
|
|
$edit_label = pht('Edit This Instance');
|
2015-06-10 02:22:08 +02:00
|
|
|
} else {
|
2016-07-13 00:44:11 +02:00
|
|
|
$edit_label = pht('Edit Event');
|
2015-06-01 00:04:48 +02:00
|
|
|
}
|
|
|
|
|
2016-03-06 19:08:49 +01:00
|
|
|
$curtain = $this->newCurtainView($event);
|
|
|
|
|
2015-06-02 16:29:48 +02:00
|
|
|
if ($edit_label && $edit_uri) {
|
2016-03-06 19:08:49 +01:00
|
|
|
$curtain->addAction(
|
2015-05-29 02:27:25 +02:00
|
|
|
id(new PhabricatorActionView())
|
2015-06-02 16:29:48 +02:00
|
|
|
->setName($edit_label)
|
2015-05-29 02:27:25 +02:00
|
|
|
->setIcon('fa-pencil')
|
2015-06-02 16:29:48 +02:00
|
|
|
->setHref($this->getApplicationURI($edit_uri))
|
2015-05-29 02:27:25 +02:00
|
|
|
->setDisabled(!$can_edit)
|
|
|
|
->setWorkflow(!$can_edit));
|
|
|
|
}
|
2014-02-06 19:10:27 +01:00
|
|
|
|
2015-04-30 03:18:27 +02:00
|
|
|
if ($is_attending) {
|
2016-03-06 19:08:49 +01:00
|
|
|
$curtain->addAction(
|
2015-04-30 03:18:27 +02:00
|
|
|
id(new PhabricatorActionView())
|
|
|
|
->setName(pht('Decline Event'))
|
|
|
|
->setIcon('fa-user-times')
|
|
|
|
->setHref($this->getApplicationURI("event/join/{$id}/"))
|
|
|
|
->setWorkflow(true));
|
|
|
|
} else {
|
2016-03-06 19:08:49 +01:00
|
|
|
$curtain->addAction(
|
2015-04-30 03:18:27 +02:00
|
|
|
id(new PhabricatorActionView())
|
|
|
|
->setName(pht('Join Event'))
|
|
|
|
->setIcon('fa-user-plus')
|
|
|
|
->setHref($this->getApplicationURI("event/join/{$id}/"))
|
|
|
|
->setWorkflow(true));
|
|
|
|
}
|
|
|
|
|
2015-06-06 22:03:21 +02:00
|
|
|
$cancel_uri = $this->getApplicationURI("event/cancel/{$id}/");
|
Generate "stub" events earlier, so more infrastructure works with Calendar
Summary:
Ref T9275. When you create a recurring event which recurs forever, we want to avoid writing an infinite number of rows to the database.
Currently, we write a row to the database right before you edit the event. Until then, we refer to it as `E123/999` or whatever ("instance 999 of event 123").
This creates a big mess with trying to make recurring events work with EditEngine, Subscriptions, Projects, Flags, Tokens, etc -- all of this stuff assumes that whatever you're working with has a PHID.
I poked at letting this stuff work without a PHID a little bit, but that looked like a gigantic mess.
Instead, generate an event "stub" a little sooner (when you look at the event detail page). This is basically just an ID/PHID to refer to the instance.
Then, when you edit the stub, "materialize" it into a real event.
This still has some issues, but I think it's more promising than the other approach was.
Also:
- Removes dead user profile calendar controller.
- Replaces comments with EditEngine comments.
Test Plan:
- Commented on a recurring event.
- Awarded tokens to a recurring event.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T9275
Differential Revision: https://secure.phabricator.com/D16248
2016-07-07 16:19:58 +02:00
|
|
|
$cancel_disabled = !$can_edit;
|
2015-06-06 22:03:21 +02:00
|
|
|
|
Generate "stub" events earlier, so more infrastructure works with Calendar
Summary:
Ref T9275. When you create a recurring event which recurs forever, we want to avoid writing an infinite number of rows to the database.
Currently, we write a row to the database right before you edit the event. Until then, we refer to it as `E123/999` or whatever ("instance 999 of event 123").
This creates a big mess with trying to make recurring events work with EditEngine, Subscriptions, Projects, Flags, Tokens, etc -- all of this stuff assumes that whatever you're working with has a PHID.
I poked at letting this stuff work without a PHID a little bit, but that looked like a gigantic mess.
Instead, generate an event "stub" a little sooner (when you look at the event detail page). This is basically just an ID/PHID to refer to the instance.
Then, when you edit the stub, "materialize" it into a real event.
This still has some issues, but I think it's more promising than the other approach was.
Also:
- Removes dead user profile calendar controller.
- Replaces comments with EditEngine comments.
Test Plan:
- Commented on a recurring event.
- Awarded tokens to a recurring event.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T9275
Differential Revision: https://secure.phabricator.com/D16248
2016-07-07 16:19:58 +02:00
|
|
|
if ($event->isChildEvent()) {
|
2015-06-06 22:03:21 +02:00
|
|
|
$cancel_label = pht('Cancel This Instance');
|
|
|
|
$reinstate_label = pht('Reinstate This Instance');
|
Generate "stub" events earlier, so more infrastructure works with Calendar
Summary:
Ref T9275. When you create a recurring event which recurs forever, we want to avoid writing an infinite number of rows to the database.
Currently, we write a row to the database right before you edit the event. Until then, we refer to it as `E123/999` or whatever ("instance 999 of event 123").
This creates a big mess with trying to make recurring events work with EditEngine, Subscriptions, Projects, Flags, Tokens, etc -- all of this stuff assumes that whatever you're working with has a PHID.
I poked at letting this stuff work without a PHID a little bit, but that looked like a gigantic mess.
Instead, generate an event "stub" a little sooner (when you look at the event detail page). This is basically just an ID/PHID to refer to the instance.
Then, when you edit the stub, "materialize" it into a real event.
This still has some issues, but I think it's more promising than the other approach was.
Also:
- Removes dead user profile calendar controller.
- Replaces comments with EditEngine comments.
Test Plan:
- Commented on a recurring event.
- Awarded tokens to a recurring event.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T9275
Differential Revision: https://secure.phabricator.com/D16248
2016-07-07 16:19:58 +02:00
|
|
|
|
|
|
|
if ($event->getParentEvent()->getIsCancelled()) {
|
|
|
|
$cancel_disabled = true;
|
|
|
|
}
|
|
|
|
} else if ($event->isParentEvent()) {
|
2016-04-20 18:52:15 +02:00
|
|
|
$cancel_label = pht('Cancel All');
|
|
|
|
$reinstate_label = pht('Reinstate All');
|
2015-06-06 22:03:21 +02:00
|
|
|
} else {
|
|
|
|
$cancel_label = pht('Cancel Event');
|
|
|
|
$reinstate_label = pht('Reinstate Event');
|
|
|
|
}
|
|
|
|
|
Canceling calendar events should deactivate the event
Summary: Closes T7943, Canceling calendar event should deactivate the event instead of destroying data.
Test Plan: Create an event, cancel it, see changed status icon, query for active events, event should not appear, query for deactivated events, event should appear in results.
Reviewers: #blessed_reviewers, epriestley
Reviewed By: #blessed_reviewers, epriestley
Subscribers: Korvin, epriestley
Maniphest Tasks: T7943
Differential Revision: https://secure.phabricator.com/D12604
2015-04-29 17:39:39 +02:00
|
|
|
if ($is_cancelled) {
|
2016-03-06 19:08:49 +01:00
|
|
|
$curtain->addAction(
|
Canceling calendar events should deactivate the event
Summary: Closes T7943, Canceling calendar event should deactivate the event instead of destroying data.
Test Plan: Create an event, cancel it, see changed status icon, query for active events, event should not appear, query for deactivated events, event should appear in results.
Reviewers: #blessed_reviewers, epriestley
Reviewed By: #blessed_reviewers, epriestley
Subscribers: Korvin, epriestley
Maniphest Tasks: T7943
Differential Revision: https://secure.phabricator.com/D12604
2015-04-29 17:39:39 +02:00
|
|
|
id(new PhabricatorActionView())
|
2015-06-06 22:03:21 +02:00
|
|
|
->setName($reinstate_label)
|
Canceling calendar events should deactivate the event
Summary: Closes T7943, Canceling calendar event should deactivate the event instead of destroying data.
Test Plan: Create an event, cancel it, see changed status icon, query for active events, event should not appear, query for deactivated events, event should appear in results.
Reviewers: #blessed_reviewers, epriestley
Reviewed By: #blessed_reviewers, epriestley
Subscribers: Korvin, epriestley
Maniphest Tasks: T7943
Differential Revision: https://secure.phabricator.com/D12604
2015-04-29 17:39:39 +02:00
|
|
|
->setIcon('fa-plus')
|
2015-06-06 22:03:21 +02:00
|
|
|
->setHref($cancel_uri)
|
|
|
|
->setDisabled($cancel_disabled)
|
Canceling calendar events should deactivate the event
Summary: Closes T7943, Canceling calendar event should deactivate the event instead of destroying data.
Test Plan: Create an event, cancel it, see changed status icon, query for active events, event should not appear, query for deactivated events, event should appear in results.
Reviewers: #blessed_reviewers, epriestley
Reviewed By: #blessed_reviewers, epriestley
Subscribers: Korvin, epriestley
Maniphest Tasks: T7943
Differential Revision: https://secure.phabricator.com/D12604
2015-04-29 17:39:39 +02:00
|
|
|
->setWorkflow(true));
|
|
|
|
} else {
|
2016-03-06 19:08:49 +01:00
|
|
|
$curtain->addAction(
|
Canceling calendar events should deactivate the event
Summary: Closes T7943, Canceling calendar event should deactivate the event instead of destroying data.
Test Plan: Create an event, cancel it, see changed status icon, query for active events, event should not appear, query for deactivated events, event should appear in results.
Reviewers: #blessed_reviewers, epriestley
Reviewed By: #blessed_reviewers, epriestley
Subscribers: Korvin, epriestley
Maniphest Tasks: T7943
Differential Revision: https://secure.phabricator.com/D12604
2015-04-29 17:39:39 +02:00
|
|
|
id(new PhabricatorActionView())
|
2015-06-06 22:03:21 +02:00
|
|
|
->setName($cancel_label)
|
Canceling calendar events should deactivate the event
Summary: Closes T7943, Canceling calendar event should deactivate the event instead of destroying data.
Test Plan: Create an event, cancel it, see changed status icon, query for active events, event should not appear, query for deactivated events, event should appear in results.
Reviewers: #blessed_reviewers, epriestley
Reviewed By: #blessed_reviewers, epriestley
Subscribers: Korvin, epriestley
Maniphest Tasks: T7943
Differential Revision: https://secure.phabricator.com/D12604
2015-04-29 17:39:39 +02:00
|
|
|
->setIcon('fa-times')
|
2015-06-06 22:03:21 +02:00
|
|
|
->setHref($cancel_uri)
|
|
|
|
->setDisabled($cancel_disabled)
|
Canceling calendar events should deactivate the event
Summary: Closes T7943, Canceling calendar event should deactivate the event instead of destroying data.
Test Plan: Create an event, cancel it, see changed status icon, query for active events, event should not appear, query for deactivated events, event should appear in results.
Reviewers: #blessed_reviewers, epriestley
Reviewed By: #blessed_reviewers, epriestley
Subscribers: Korvin, epriestley
Maniphest Tasks: T7943
Differential Revision: https://secure.phabricator.com/D12604
2015-04-29 17:39:39 +02:00
|
|
|
->setWorkflow(true));
|
|
|
|
}
|
2014-02-06 19:10:27 +01:00
|
|
|
|
2016-03-06 19:08:49 +01:00
|
|
|
return $curtain;
|
2016-03-03 03:09:13 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
private function buildPropertySection(
|
|
|
|
PhabricatorCalendarEvent $event) {
|
|
|
|
$viewer = $this->getViewer();
|
|
|
|
|
|
|
|
$properties = id(new PHUIPropertyListView())
|
|
|
|
->setUser($viewer);
|
|
|
|
|
2015-05-08 17:08:26 +02:00
|
|
|
if ($event->getIsAllDay()) {
|
2016-07-12 00:29:11 +02:00
|
|
|
$date_start = phabricator_date($event->getViewerDateFrom(), $viewer);
|
|
|
|
$date_end = phabricator_date($event->getViewerDateTo(), $viewer);
|
2015-05-08 17:08:26 +02:00
|
|
|
|
|
|
|
if ($date_start == $date_end) {
|
|
|
|
$properties->addProperty(
|
|
|
|
pht('Time'),
|
2016-07-12 00:29:11 +02:00
|
|
|
phabricator_date($event->getViewerDateFrom(), $viewer));
|
2015-05-08 17:08:26 +02:00
|
|
|
} else {
|
|
|
|
$properties->addProperty(
|
|
|
|
pht('Starts'),
|
2016-07-12 00:29:11 +02:00
|
|
|
phabricator_date($event->getViewerDateFrom(), $viewer));
|
2015-05-08 17:08:26 +02:00
|
|
|
$properties->addProperty(
|
|
|
|
pht('Ends'),
|
2016-07-12 00:29:11 +02:00
|
|
|
phabricator_date($event->getViewerDateTo(), $viewer));
|
2015-05-08 17:08:26 +02:00
|
|
|
}
|
|
|
|
} else {
|
|
|
|
$properties->addProperty(
|
|
|
|
pht('Starts'),
|
2016-07-12 00:29:11 +02:00
|
|
|
phabricator_datetime($event->getViewerDateFrom(), $viewer));
|
2014-02-06 19:10:27 +01:00
|
|
|
|
2015-05-08 17:08:26 +02:00
|
|
|
$properties->addProperty(
|
|
|
|
pht('Ends'),
|
2016-07-12 00:29:11 +02:00
|
|
|
phabricator_datetime($event->getViewerDateTo(), $viewer));
|
2015-05-08 17:08:26 +02:00
|
|
|
}
|
2014-02-06 19:10:27 +01:00
|
|
|
|
2015-05-29 02:27:25 +02:00
|
|
|
if ($event->getIsRecurring()) {
|
|
|
|
$properties->addProperty(
|
|
|
|
pht('Recurs'),
|
2015-05-29 22:58:53 +02:00
|
|
|
ucwords(idx($event->getRecurrenceFrequency(), 'rule')));
|
2015-06-02 03:56:11 +02:00
|
|
|
|
|
|
|
if ($event->getRecurrenceEndDate()) {
|
|
|
|
$properties->addProperty(
|
|
|
|
pht('Recurrence Ends'),
|
|
|
|
phabricator_datetime($event->getRecurrenceEndDate(), $viewer));
|
|
|
|
}
|
|
|
|
|
2015-06-01 00:04:48 +02:00
|
|
|
if ($event->getInstanceOfEventPHID()) {
|
2015-05-29 22:58:53 +02:00
|
|
|
$properties->addProperty(
|
|
|
|
pht('Recurrence of Event'),
|
2015-06-16 22:41:55 +02:00
|
|
|
pht('%s of %s',
|
|
|
|
$event->getSequenceIndex(),
|
|
|
|
$viewer->renderHandle($event->getInstanceOfEventPHID())->render()));
|
2015-05-29 22:58:53 +02:00
|
|
|
}
|
2015-05-29 02:27:25 +02:00
|
|
|
}
|
|
|
|
|
2015-05-05 19:26:15 +02:00
|
|
|
$properties->addProperty(
|
|
|
|
pht('Host'),
|
|
|
|
$viewer->renderHandle($event->getUserPHID()));
|
|
|
|
|
2015-04-29 22:51:09 +02:00
|
|
|
$invitees = $event->getInvitees();
|
2015-05-05 19:26:15 +02:00
|
|
|
foreach ($invitees as $key => $invitee) {
|
2015-04-30 00:31:02 +02:00
|
|
|
if ($invitee->isUninvited()) {
|
2015-05-05 19:26:15 +02:00
|
|
|
unset($invitees[$key]);
|
2015-04-30 00:31:02 +02:00
|
|
|
}
|
2015-04-29 22:51:09 +02:00
|
|
|
}
|
|
|
|
|
2015-05-05 19:26:15 +02:00
|
|
|
if ($invitees) {
|
|
|
|
$invitee_list = new PHUIStatusListView();
|
2015-05-05 21:29:04 +02:00
|
|
|
|
|
|
|
$icon_invited = PHUIStatusItemView::ICON_OPEN;
|
|
|
|
$icon_attending = PHUIStatusItemView::ICON_ACCEPT;
|
|
|
|
$icon_declined = PHUIStatusItemView::ICON_REJECT;
|
|
|
|
|
|
|
|
$status_invited = PhabricatorCalendarEventInvitee::STATUS_INVITED;
|
|
|
|
$status_attending = PhabricatorCalendarEventInvitee::STATUS_ATTENDING;
|
|
|
|
$status_declined = PhabricatorCalendarEventInvitee::STATUS_DECLINED;
|
|
|
|
|
|
|
|
$icon_map = array(
|
|
|
|
$status_invited => $icon_invited,
|
|
|
|
$status_attending => $icon_attending,
|
|
|
|
$status_declined => $icon_declined,
|
|
|
|
);
|
|
|
|
|
|
|
|
$icon_color_map = array(
|
|
|
|
$status_invited => null,
|
|
|
|
$status_attending => 'green',
|
|
|
|
$status_declined => 'red',
|
|
|
|
);
|
|
|
|
|
2015-05-05 19:26:15 +02:00
|
|
|
foreach ($invitees as $invitee) {
|
|
|
|
$item = new PHUIStatusItemView();
|
|
|
|
$invitee_phid = $invitee->getInviteePHID();
|
2015-05-05 21:29:04 +02:00
|
|
|
$status = $invitee->getStatus();
|
2015-05-05 19:26:15 +02:00
|
|
|
$target = $viewer->renderHandle($invitee_phid);
|
2015-05-05 21:29:04 +02:00
|
|
|
$icon = $icon_map[$status];
|
|
|
|
$icon_color = $icon_color_map[$status];
|
|
|
|
|
|
|
|
$item->setIcon($icon, $icon_color)
|
2015-05-05 19:26:15 +02:00
|
|
|
->setTarget($target);
|
|
|
|
$invitee_list->addItem($item);
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
$invitee_list = phutil_tag(
|
|
|
|
'em',
|
|
|
|
array(),
|
|
|
|
pht('None'));
|
|
|
|
}
|
2015-05-04 00:29:42 +02:00
|
|
|
|
2015-04-29 22:51:09 +02:00
|
|
|
$properties->addProperty(
|
|
|
|
pht('Invitees'),
|
|
|
|
$invitee_list);
|
|
|
|
|
2015-04-28 19:40:35 +02:00
|
|
|
$properties->invokeWillRenderEvent();
|
|
|
|
|
2015-05-19 22:09:28 +02:00
|
|
|
$properties->addProperty(
|
|
|
|
pht('Icon'),
|
2015-12-16 16:53:13 +01:00
|
|
|
id(new PhabricatorCalendarIconSet())
|
|
|
|
->getIconLabel($event->getIcon()));
|
2015-05-19 22:09:28 +02:00
|
|
|
|
2016-03-03 03:09:13 +01:00
|
|
|
return $properties;
|
|
|
|
}
|
|
|
|
|
|
|
|
private function buildDescriptionView(
|
|
|
|
PhabricatorCalendarEvent $event) {
|
|
|
|
$viewer = $this->getViewer();
|
|
|
|
|
|
|
|
$properties = id(new PHUIPropertyListView())
|
|
|
|
->setUser($viewer);
|
|
|
|
|
2015-06-19 17:32:50 +02:00
|
|
|
if (strlen($event->getDescription())) {
|
2016-02-16 22:52:12 +01:00
|
|
|
$description = new PHUIRemarkupView($viewer, $event->getDescription());
|
2015-06-19 17:32:50 +02:00
|
|
|
$properties->addTextContent($description);
|
2016-03-03 03:09:13 +01:00
|
|
|
return $properties;
|
2015-06-19 17:32:50 +02:00
|
|
|
}
|
2014-02-18 01:08:25 +01:00
|
|
|
|
2016-03-03 03:09:13 +01:00
|
|
|
return null;
|
2014-02-06 19:10:27 +01:00
|
|
|
}
|
|
|
|
|
Generate "stub" events earlier, so more infrastructure works with Calendar
Summary:
Ref T9275. When you create a recurring event which recurs forever, we want to avoid writing an infinite number of rows to the database.
Currently, we write a row to the database right before you edit the event. Until then, we refer to it as `E123/999` or whatever ("instance 999 of event 123").
This creates a big mess with trying to make recurring events work with EditEngine, Subscriptions, Projects, Flags, Tokens, etc -- all of this stuff assumes that whatever you're working with has a PHID.
I poked at letting this stuff work without a PHID a little bit, but that looked like a gigantic mess.
Instead, generate an event "stub" a little sooner (when you look at the event detail page). This is basically just an ID/PHID to refer to the instance.
Then, when you edit the stub, "materialize" it into a real event.
This still has some issues, but I think it's more promising than the other approach was.
Also:
- Removes dead user profile calendar controller.
- Replaces comments with EditEngine comments.
Test Plan:
- Commented on a recurring event.
- Awarded tokens to a recurring event.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T9275
Differential Revision: https://secure.phabricator.com/D16248
2016-07-07 16:19:58 +02:00
|
|
|
|
|
|
|
private function loadEvent() {
|
|
|
|
$request = $this->getRequest();
|
|
|
|
$viewer = $this->getViewer();
|
|
|
|
|
|
|
|
$id = $request->getURIData('id');
|
|
|
|
$sequence = $request->getURIData('sequence');
|
|
|
|
|
|
|
|
// We're going to figure out which event you're trying to look at. Most of
|
|
|
|
// the time this is simple, but you may be looking at an instance of a
|
|
|
|
// recurring event which we haven't generated an object for.
|
|
|
|
|
|
|
|
// If you are, we're going to generate a "stub" event so we have a real
|
|
|
|
// ID and PHID to work with, since the rest of the infrastructure relies
|
|
|
|
// on these identifiers existing.
|
|
|
|
|
|
|
|
// Load the event identified by ID first.
|
|
|
|
$event = id(new PhabricatorCalendarEventQuery())
|
|
|
|
->setViewer($viewer)
|
|
|
|
->withIDs(array($id))
|
|
|
|
->executeOne();
|
|
|
|
if (!$event) {
|
|
|
|
return null;
|
|
|
|
}
|
|
|
|
|
|
|
|
// If we aren't looking at an instance of this event, this is a completely
|
|
|
|
// normal request and we can just return this event.
|
|
|
|
if (!$sequence) {
|
|
|
|
return $event;
|
|
|
|
}
|
|
|
|
|
|
|
|
// When you view "E123/999", E123 is normally the parent event. However,
|
|
|
|
// you might visit a different instance first instead and then fiddle
|
|
|
|
// with the URI. If the event we're looking at is a child, we are going
|
|
|
|
// to act on the parent instead.
|
|
|
|
if ($event->isChildEvent()) {
|
|
|
|
$event = $event->getParentEvent();
|
|
|
|
}
|
|
|
|
|
|
|
|
// Try to load the instance. If it already exists, we're all done and
|
|
|
|
// can just return it.
|
|
|
|
$instance = id(new PhabricatorCalendarEventQuery())
|
|
|
|
->setViewer($viewer)
|
|
|
|
->withInstanceSequencePairs(
|
|
|
|
array(
|
|
|
|
array($event->getPHID(), $sequence),
|
|
|
|
))
|
|
|
|
->executeOne();
|
|
|
|
if ($instance) {
|
|
|
|
return $instance;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!$viewer->isLoggedIn()) {
|
|
|
|
throw new Exception(
|
|
|
|
pht(
|
|
|
|
'This event instance has not been created yet. Log in to create '.
|
|
|
|
'it.'));
|
|
|
|
}
|
|
|
|
|
|
|
|
$instance = $event->newStub($viewer, $sequence);
|
|
|
|
|
|
|
|
return $instance;
|
|
|
|
}
|
|
|
|
|
2014-02-06 19:10:27 +01:00
|
|
|
}
|