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();
|
2016-07-15 23:17:58 +02:00
|
|
|
|
2016-10-04 18:47:38 +02:00
|
|
|
$start = $event->newStartDateTime()
|
|
|
|
->newPHPDateTime();
|
2016-07-15 23:17:58 +02:00
|
|
|
|
|
|
|
$crumbs->addTextCrumb(
|
|
|
|
$start->format('F Y'),
|
|
|
|
'/calendar/query/month/'.$start->format('Y/m/'));
|
|
|
|
|
|
|
|
$crumbs->addTextCrumb(
|
|
|
|
$start->format('D jS'),
|
|
|
|
'/calendar/query/month/'.$start->format('Y/m/d/'));
|
|
|
|
|
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
|
|
|
$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-07-14 14:07:06 +02:00
|
|
|
$subheader = $this->buildSubheaderView($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);
|
2016-07-28 16:51:54 +02:00
|
|
|
$recurring = $this->buildRecurringSection($event);
|
2016-03-03 03:09:13 +01:00
|
|
|
$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-07-28 16:51:54 +02:00
|
|
|
$details_header = id(new PHUIHeaderView())
|
|
|
|
->setHeader(pht('Details'));
|
|
|
|
$recurring_header = $this->buildRecurringHeader($event);
|
|
|
|
|
2016-03-03 03:09:13 +01:00
|
|
|
$view = id(new PHUITwoColumnView())
|
|
|
|
->setHeader($header)
|
2016-07-14 14:07:06 +02:00
|
|
|
->setSubheader($subheader)
|
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-10-05 20:30:56 +02:00
|
|
|
->addPropertySection(pht('Description'), $description)
|
2016-07-28 16:51:54 +02:00
|
|
|
->addPropertySection($recurring_header, $recurring)
|
2016-10-05 20:30:56 +02:00
|
|
|
->addPropertySection($details_header, $details);
|
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();
|
|
|
|
|
2016-07-14 13:50:38 +02:00
|
|
|
if ($event->isCancelledEvent()) {
|
|
|
|
$icon = 'fa-ban';
|
|
|
|
$color = 'red';
|
|
|
|
$status = pht('Cancelled');
|
|
|
|
} else {
|
|
|
|
$icon = 'fa-check';
|
|
|
|
$color = 'bluegrey';
|
|
|
|
$status = pht('Active');
|
|
|
|
}
|
2014-02-06 19:10:27 +01:00
|
|
|
|
2015-04-30 04:48:46 +02:00
|
|
|
$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)
|
2016-07-14 13:50:38 +02:00
|
|
|
->setHeaderIcon($event->getIcon());
|
2015-04-30 04:48:46 +02:00
|
|
|
|
2016-07-28 16:51:54 +02:00
|
|
|
foreach ($this->buildRSVPActions($event) as $action) {
|
|
|
|
$header->addActionLink($action);
|
2015-04-30 04:48:46 +02:00
|
|
|
}
|
2016-07-28 16:51:54 +02:00
|
|
|
|
2015-04-30 04:48:46 +02:00
|
|
|
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();
|
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');
|
|
|
|
}
|
|
|
|
|
2016-07-14 13:50:38 +02:00
|
|
|
if ($event->isCancelledEvent()) {
|
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-09-15 15:27:20 +02:00
|
|
|
$ics_name = $event->getICSFilename();
|
|
|
|
$export_uri = $this->getApplicationURI("event/export/{$id}/{$ics_name}");
|
2016-09-15 02:16:54 +02:00
|
|
|
|
|
|
|
$curtain->addAction(
|
|
|
|
id(new PhabricatorActionView())
|
|
|
|
->setName(pht('Export as .ics'))
|
|
|
|
->setIcon('fa-download')
|
2016-09-15 15:27:20 +02:00
|
|
|
->setHref($export_uri));
|
2016-09-15 02:16:54 +02: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-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();
|
|
|
|
|
2016-03-03 03:09:13 +01:00
|
|
|
return $properties;
|
|
|
|
}
|
|
|
|
|
2016-07-28 16:51:54 +02:00
|
|
|
private function buildRecurringHeader(PhabricatorCalendarEvent $event) {
|
|
|
|
$viewer = $this->getViewer();
|
|
|
|
|
|
|
|
if (!$event->getIsRecurring()) {
|
|
|
|
return null;
|
|
|
|
}
|
|
|
|
|
|
|
|
$header = id(new PHUIHeaderView())
|
|
|
|
->setHeader(pht('Recurring Event'));
|
|
|
|
|
|
|
|
$sequence = $event->getSequenceIndex();
|
|
|
|
if ($event->isParentEvent()) {
|
|
|
|
$parent = $event;
|
|
|
|
} else {
|
|
|
|
$parent = $event->getParentEvent();
|
|
|
|
}
|
|
|
|
|
2016-09-08 18:12:38 +02:00
|
|
|
if ($parent->isValidSequenceIndex($viewer, $sequence + 1)) {
|
|
|
|
$next_uri = $parent->getURI().'/'.($sequence + 1);
|
|
|
|
$has_next = true;
|
|
|
|
} else {
|
|
|
|
$next_uri = null;
|
|
|
|
$has_next = false;
|
|
|
|
}
|
|
|
|
|
2016-07-28 16:51:54 +02:00
|
|
|
if ($sequence) {
|
|
|
|
if ($sequence > 1) {
|
|
|
|
$previous_uri = $parent->getURI().'/'.($sequence - 1);
|
|
|
|
} else {
|
|
|
|
$previous_uri = $parent->getURI();
|
|
|
|
}
|
|
|
|
$has_previous = true;
|
|
|
|
} else {
|
|
|
|
$has_previous = false;
|
|
|
|
$previous_uri = null;
|
|
|
|
}
|
|
|
|
|
|
|
|
$prev_button = id(new PHUIButtonView())
|
|
|
|
->setTag('a')
|
|
|
|
->setIcon('fa-chevron-left')
|
|
|
|
->setHref($previous_uri)
|
|
|
|
->setDisabled(!$has_previous)
|
|
|
|
->setText(pht('Previous'));
|
|
|
|
|
|
|
|
$next_button = id(new PHUIButtonView())
|
|
|
|
->setTag('a')
|
|
|
|
->setIcon('fa-chevron-right')
|
|
|
|
->setHref($next_uri)
|
2016-09-08 18:12:38 +02:00
|
|
|
->setDisabled(!$has_next)
|
2016-07-28 16:51:54 +02:00
|
|
|
->setText(pht('Next'));
|
|
|
|
|
|
|
|
$header
|
|
|
|
->addActionLink($next_button)
|
|
|
|
->addActionLink($prev_button);
|
|
|
|
|
|
|
|
return $header;
|
|
|
|
}
|
|
|
|
|
|
|
|
private function buildRecurringSection(PhabricatorCalendarEvent $event) {
|
|
|
|
$viewer = $this->getViewer();
|
|
|
|
|
|
|
|
if (!$event->getIsRecurring()) {
|
|
|
|
return null;
|
|
|
|
}
|
|
|
|
|
|
|
|
$properties = id(new PHUIPropertyListView())
|
|
|
|
->setUser($viewer);
|
|
|
|
|
|
|
|
$is_parent = $event->isParentEvent();
|
|
|
|
if ($is_parent) {
|
|
|
|
$parent_link = null;
|
|
|
|
} else {
|
|
|
|
$parent = $event->getParentEvent();
|
|
|
|
$parent_link = $viewer
|
|
|
|
->renderHandle($parent->getPHID())
|
|
|
|
->render();
|
|
|
|
}
|
|
|
|
|
2016-10-05 19:51:09 +02:00
|
|
|
$rrule = $event->newRecurrenceRule();
|
|
|
|
|
|
|
|
if ($rrule) {
|
|
|
|
$frequency = $rrule->getFrequency();
|
|
|
|
} else {
|
|
|
|
$frequency = null;
|
|
|
|
}
|
|
|
|
|
|
|
|
switch ($frequency) {
|
|
|
|
case PhutilCalendarRecurrenceRule::FREQUENCY_DAILY:
|
2016-07-28 16:51:54 +02:00
|
|
|
if ($is_parent) {
|
|
|
|
$message = pht('This event repeats every day.');
|
|
|
|
} else {
|
|
|
|
$message = pht(
|
|
|
|
'This event is an instance of %s, and repeats every day.',
|
|
|
|
$parent_link);
|
|
|
|
}
|
|
|
|
break;
|
2016-10-05 19:51:09 +02:00
|
|
|
case PhutilCalendarRecurrenceRule::FREQUENCY_WEEKLY:
|
2016-07-28 16:51:54 +02:00
|
|
|
if ($is_parent) {
|
|
|
|
$message = pht('This event repeats every week.');
|
|
|
|
} else {
|
|
|
|
$message = pht(
|
|
|
|
'This event is an instance of %s, and repeats every week.',
|
|
|
|
$parent_link);
|
|
|
|
}
|
|
|
|
break;
|
2016-10-05 19:51:09 +02:00
|
|
|
case PhutilCalendarRecurrenceRule::FREQUENCY_MONTHLY:
|
2016-07-28 16:51:54 +02:00
|
|
|
if ($is_parent) {
|
|
|
|
$message = pht('This event repeats every month.');
|
|
|
|
} else {
|
|
|
|
$message = pht(
|
|
|
|
'This event is an instance of %s, and repeats every month.',
|
|
|
|
$parent_link);
|
|
|
|
}
|
|
|
|
break;
|
2016-10-05 19:51:09 +02:00
|
|
|
case PhutilCalendarRecurrenceRule::FREQUENCY_YEARLY:
|
2016-07-28 16:51:54 +02:00
|
|
|
if ($is_parent) {
|
|
|
|
$message = pht('This event repeats every year.');
|
|
|
|
} else {
|
|
|
|
$message = pht(
|
|
|
|
'This event is an instance of %s, and repeats every year.',
|
|
|
|
$parent_link);
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
$properties->addProperty(pht('Event Series'), $message);
|
|
|
|
|
|
|
|
return $properties;
|
|
|
|
}
|
|
|
|
|
2016-03-03 03:09:13 +01:00
|
|
|
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.'));
|
|
|
|
}
|
|
|
|
|
2016-09-08 18:12:38 +02:00
|
|
|
if (!$event->isValidSequenceIndex($viewer, $sequence)) {
|
|
|
|
return null;
|
|
|
|
}
|
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
|
|
|
|
2016-09-08 18:12:38 +02:00
|
|
|
return $event->newStub($viewer, $sequence);
|
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
|
|
|
}
|
|
|
|
|
2016-07-14 14:07:06 +02:00
|
|
|
private function buildSubheaderView(PhabricatorCalendarEvent $event) {
|
|
|
|
$viewer = $this->getViewer();
|
|
|
|
|
|
|
|
$host_phid = $event->getHostPHID();
|
|
|
|
|
|
|
|
$handles = $viewer->loadHandles(array($host_phid));
|
|
|
|
$handle = $handles[$host_phid];
|
|
|
|
|
|
|
|
$host = $viewer->renderHandle($host_phid);
|
|
|
|
$host = phutil_tag('strong', array(), $host);
|
|
|
|
|
|
|
|
$image_uri = $handles[$host_phid]->getImageURI();
|
|
|
|
$image_href = $handles[$host_phid]->getURI();
|
|
|
|
|
|
|
|
$date = $event->renderEventDate($viewer, true);
|
|
|
|
|
|
|
|
$content = pht('Hosted by %s on %s.', $host, $date);
|
|
|
|
|
|
|
|
return id(new PHUIHeadThingView())
|
|
|
|
->setImage($image_uri)
|
|
|
|
->setImageHref($image_href)
|
|
|
|
->setContent($content);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2016-07-28 16:51:54 +02:00
|
|
|
private function buildRSVPActions(PhabricatorCalendarEvent $event) {
|
|
|
|
$viewer = $this->getViewer();
|
|
|
|
$id = $event->getID();
|
|
|
|
|
|
|
|
$invite_status = $event->getUserInviteStatus($viewer->getPHID());
|
|
|
|
$status_invited = PhabricatorCalendarEventInvitee::STATUS_INVITED;
|
|
|
|
$is_invite_pending = ($invite_status == $status_invited);
|
|
|
|
if (!$is_invite_pending) {
|
|
|
|
return array();
|
|
|
|
}
|
|
|
|
|
|
|
|
$decline_button = id(new PHUIButtonView())
|
|
|
|
->setTag('a')
|
|
|
|
->setIcon('fa-times grey')
|
|
|
|
->setHref($this->getApplicationURI("/event/decline/{$id}/"))
|
|
|
|
->setWorkflow(true)
|
|
|
|
->setText(pht('Decline'));
|
|
|
|
|
|
|
|
$accept_button = id(new PHUIButtonView())
|
|
|
|
->setTag('a')
|
|
|
|
->setIcon('fa-check green')
|
|
|
|
->setHref($this->getApplicationURI("/event/accept/{$id}/"))
|
|
|
|
->setWorkflow(true)
|
|
|
|
->setText(pht('Accept'));
|
|
|
|
|
|
|
|
return array($decline_button, $accept_button);
|
|
|
|
}
|
|
|
|
|
2014-02-06 19:10:27 +01:00
|
|
|
}
|