1
0
Fork 0
mirror of https://we.phorge.it/source/phorge.git synced 2024-11-25 00:02:41 +01:00
Commit graph

116 commits

Author SHA1 Message Date
epriestley
850fcf0207 Move event recurrence controls to a separate page on the workflow
Summary:
Ref T11326. Currently, the "Create Event" form is pretty wordy. One particular culprit is the "recurring" controls, which are (presumably) rarely used and visually complex.

  - Reflow the default form to hopefully feel a little better.
  - Move recurrence stuff to a separate workflow.

Test Plan:
{F1891355}

{F1891356}

{F1891357}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T11326

Differential Revision: https://secure.phabricator.com/D16774
2016-10-31 14:13:36 -07:00
epriestley
e1a9b76945 Give organizers in ICS exports a dummy email address to placate Gmail
Summary:
Ref T10747. In the in-email ICS event card that Gmail shows, it has a "Who" field which reads "Unknown Organizer*" if the URI for the organizer isn't email-address-like.

Previously, we used a URI like `https://phabricator.install.com/p/username`, which I think is OK as far as RFC 5545 is concerned, but Gmail doesn't like it.

Instead, use `PHID-USER-asdfa@phabricator.install.com`, which doesn't go anywhere, but makes Gmail happy. Users don't normally see this URI anyway.

Test Plan:
Got a readable "Who" in Gmail when importing an event exported from Calendar:

{F1890571}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T10747

Differential Revision: https://secure.phabricator.com/D16772
2016-10-30 09:20:54 -07:00
epriestley
09775279a9 Support arbitary event invitees when importing events
Summary:
Ref T10747. When we import a ".ics" file, represent any attendees as simple external references.

For consistency with other areas of the product, I've avoided disclosing email addresses. We'll try to get a real name if we can.

(We store addresses and could expose or use them later, or do some kind of masking junk like "epr...ley@g...l.com" which is utterly impossible to figure out.)

Test Plan: {F1888367}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T10747

Differential Revision: https://secure.phabricator.com/D16759
2016-10-27 13:27:58 -07:00
epriestley
8e9c20c9ae Make event invitees behave a little better for stub/ghost events
Summary:
Ref T11326. Currently:

  - The month view and day view (ghosts) don't show that you're invited to a child event.
  - The detail view copies the invite list, including attending status, but only //after// it shows the page for the first time.

Instead, for now, just do this:

  - Ghosts/stubs use the parent invite list, but treat everyone as "invited".
  - Materializing a stub just saves the list as-is (i.e., invited, not a copy of attending/declined/etc).

This behavior may need some refining eventually but is at least reasonable (not obviously bad/buggy).

Test Plan:
  - Viewed month/day views, now shown as "invited".
  - Viewed detail view, now invitee list shows up properly.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T11326

Differential Revision: https://secure.phabricator.com/D16758
2016-10-27 13:08:56 -07:00
epriestley
4c3f09a6a6 Suggest better start/end datetimes for Calendar events
Summary:
Fixes T11638.

  - Fix a regression: I broke this "round to the nearest hour" code a while ago while fiddling with datetimes.
  - Improve a beahvior: from the day view, make the menu-bar "Create Event" button default to creating an event on the day you were viewing.

Test Plan: Created events from month and day views, got nice round numbers and proper day suggestions.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T11638

Differential Revision: https://secure.phabricator.com/D16754
2016-10-26 13:10:29 -07:00
epriestley
2d7f574b9d Allow Calendar imports to be configured with hourly or daily auto-updates
Summary:
Ref T10747. For URI-based (and, in the future, Google-based) imports, we can automatically refresh them periodically.

(In the general case there's no way to get a push notification for an ICS file, so we just have to do this every-so-often.)

Test Plan:
  - Set an ICS file to update hourly.
  - Used `bin/trigger fire --id ...` to fire it artificially.
  - Saw Calendar update.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T10747

Differential Revision: https://secure.phabricator.com/D16752
2016-10-26 12:19:14 -07:00
epriestley
48666839fe Support RRULE "COUNT" for recurring events
Summary:
Ref T10747. RRULE events can repeat "UNTIL" a certain time, or a certain "COUNT" of times.

In the UI, we only support "UNTIL". Also support "COUNT".

Test Plan: Imported an event which repeats every other day, 5 times. Got 5 instances.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T10747

Differential Revision: https://secure.phabricator.com/D16749
2016-10-25 10:38:30 -07:00
epriestley
c3de8f8305 When generating Calendar event stubs, inherit import properties
Summary:
Ref T10747. Previously, importing a recurring event failed to mark the instnaces of the event as imported.

Now, we copy the source/UID/importer over.

Test Plan: Imported a recurring event, viewed event series, saw all of them marked imported.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T10747

Differential Revision: https://secure.phabricator.com/D16728
2016-10-19 09:59:24 -07:00
epriestley
d860008b6a Make event detail view more user-friendly for imported events
Summary:
Ref T10747. When viewing an imported event:

  - Make it more clear that it is imported and where it is from.
  - Add some explicit "this is imported" help.

Test Plan: Viewed imported and normal events.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T10747

Differential Revision: https://secure.phabricator.com/D16727
2016-10-19 09:58:57 -07:00
epriestley
f9f25c1e4d Allow users to drop .ics files on calendar views to import them
Summary:
Ref T10747. When a user drops a ".ics" file or a bunch of ".ics" files into a calendar view, import the events.

(Possibly we should just do this if you drop ".ics" files into any application, but we can look at that later.)

Test Plan: Dropped some .ics files into calendar views, got imports.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T10747

Differential Revision: https://secure.phabricator.com/D16722
2016-10-18 15:26:44 -07:00
epriestley
3d98558593 Add import log messages to Calendar imports
Summary: Ref T10747. When stuff goes wrong (or right) let the user know what happened.

Test Plan: {F1870139}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T10747

Differential Revision: https://secure.phabricator.com/D16704
2016-10-14 07:57:48 -07:00
epriestley
ced151e6f2 Use transactions when importing events in Calendar, and update existing events
Summary:
Ref T10747.

  - Apply what changes we can with transactions, so you can see how an event has changed and import actions are more explicit.
    - I'll hide these from email/feed soon: I want them to appear on the event, but not generate notifications, since that could be especially annoying for automated events.
  - When importing, try to update existing events if we can.

Test Plan:
Imported a ".ics" file several times with minor changes, saw them reflected in the UI with transactions.

{F1870027}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T10747

Differential Revision: https://secure.phabricator.com/D16701
2016-10-13 09:05:09 -07:00
epriestley
86a00ee4ab Make Calendar ICS imports sort of work in a crude, approximate way
Summary: Ref T10747. This barely works, but can technically import some event data.

Test Plan: Used import flow to import a ".ics" document.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T10747

Differential Revision: https://secure.phabricator.com/D16699
2016-10-12 15:29:05 -07:00
epriestley
2ab07ed29b Prepare for event imports in Calendar
Summary:
Ref T10747. Adds a bunch of stuff so we can keep track of which events we've imported from external sources.

This doesn't do anything yet: you can't actually import anything.

Test Plan:
  - Ran `bin/storage upgrade`.
  - Clicked "Imports", saw an empty wasteland.
  - Created/edited events.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T10747

Differential Revision: https://secure.phabricator.com/D16696
2016-10-12 10:45:31 -07:00
epriestley
13b4b37d30 Force a couple of Conduit results to the proper types in Calendar
Summary:
Ref T11706. Add some casts so we don't return `"0"` for `false`.

Also I forgot to document one of the things.

Test Plan: Called `calendar.event.search`.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T11706

Differential Revision: https://secure.phabricator.com/D16690
2016-10-11 13:00:17 -07:00
epriestley
d79972ecb3 Provide start/end date time via Conduit for Calendar
Summary: Fixes T11706. I think this approach (roughly: provide the information in a few different formats) is generally reasonable, and should let clients choose how much date/time magic they want to do.

Test Plan: Called `calenadar.event.search`, viewed results.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T11706

Differential Revision: https://secure.phabricator.com/D16688
2016-10-11 12:02:13 -07:00
epriestley
4819446fe5 Export recurring events and build ICS files for configured exports
Summary:
Ref T10747. This:

  - Exports recurring events properly, with RRULE + RECURRENCE-ID.
  - When exporting a part of an event series, export the whole series to ICS so it is represented faithfully.
  - Make the subscribable URL for "Export" objects work.

Test Plan:
  - Downloaded the ".ics" for a normal event, imported it into Calendar.app and Google Calendar.
  - Downloaded the ".ics" for a recurring event, imported it into Calendar.app and Google Calendar.
  - Defined an ".ics" Export of my events, subscribed to them in Calendar.app.
    - Edited an event in Phabricator.
    - Hit {key Command R} in Calendar.app, saw changes. (MAGIC!)
    - This export included recurring events, which appeared the same way in Calendar.app and Phabricator.
  - Can't import into Google Calendar from my local install easily since Google's servers can't hit my laptop, but I'll test once we deploy.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T10747

Differential Revision: https://secure.phabricator.com/D16679
2016-10-06 14:07:17 -07:00
epriestley
fa6a5a46ba Make more of the Calendar export workflow work
Summary:
Ref T10747.

  - Adds a "Use Results..." dropdown to query result pages, with actions you can take with search results (today: create export; in future: bulk edit, export as excel, make dashboard panel, etc).
  - Allows you to create an export against a query key.
    - I'm just using a text edit field for this for now.
  - Fleshes out export modes. I plan to support: public (as though you were logged out), privileged (as though you were logged in) and availability (event times, but not details).

This does not actually export stuff yet.

Test Plan: Created some exports. Viewed and listed exports.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T10747

Differential Revision: https://secure.phabricator.com/D16676
2016-10-06 04:14:29 -07:00
epriestley
49448a87c1 Rough in most of Calendar exports
Summary:
Ref T10747. Rough flow is:

  - Run a query.
  - Select a new "Export Events..." action.
  - This lets you define an "Export", which has a unique URL you can paste into Google Calendar or Calendar.app or whatever.

Most of this does nothing yet but here's the boilerplate.

Test Plan: Doesn't do anything yet.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T10747

Differential Revision: https://secure.phabricator.com/D16675
2016-10-06 04:06:35 -07:00
epriestley
3164ff68db Convert Calendar Events to use RRULE frequency constants in various other places
Summary:
Ref T10747.

  - Store recurrence as RRULEs internally.
  - Use RRULE constants.
  - Migrate existing rules to RRULEs.

Test Plan: Ran migration, nothing seemed broken?

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T10747

Differential Revision: https://secure.phabricator.com/D16670
2016-10-06 04:02:27 -07:00
epriestley
20f7de91ce Drive calendar event queries through the RRULE engine
Summary: Ref T10747. This drives event queries through RRULE, too.

Test Plan: Created recurring events, saw them appear correctly on the calendar.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T10747

Differential Revision: https://secure.phabricator.com/D16668
2016-10-06 03:57:50 -07:00
epriestley
5dfb672a80 Mostly drive Calendar event recurrence with the RRULE engine
Summary:
Ref T10737. Today, we evalute recurrence twice: once when querying, and once in all other cases. This converts the second case to use the RRULE engine.

Next up is making the query use the RRULE engine, too.

Test Plan: Created a new recurring event, iterated through it by clicking "next instance", viewed it on Calendar view.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T10737

Differential Revision: https://secure.phabricator.com/D16667
2016-10-06 03:56:52 -07:00
epriestley
d3fc1800f8 Migrate Calendar away from stored-epoch fields
Summary:
Ref T10747. This deprecates "dateFrom", "dateTo", "allDayDateFrom", "allDayDateTo", and "recurrenceEndDate".

They are replaced with "utc*Epoch" fields (for querying) and CalendarDateTime objects (for start, end, until). These objects can represent the full range of dates and times expressible in ICS format, allowing us to import a wider range of ICS events.

Test Plan:
Ran migrations, viewed/edited Calendar, didn't catch anything catastrophcially broken.

This likely needs some followups, I'll keep it local for a bit until I'm confident I didn't break anything too catastrophically. I'm retaining the old data for now so we can likely fix things if it turns out there is some sort of issue.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T10747

Differential Revision: https://secure.phabricator.com/D16664
2016-10-06 03:55:59 -07:00
epriestley
fae0ec9220 Use more CalendarDateTime and fewer epoch timestamps in Calendar
Summary: Ref T10747. Moves away from getDateFrom() / getDateTo() and makes a few more date/time methods more consistent.

Test Plan: Created, edited, viewed events.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T10747

Differential Revision: https://secure.phabricator.com/D16663
2016-10-06 03:52:59 -07:00
epriestley
37f35e9ecc Remove "viewerDateFrom" / "viewerDateTo" in favor of CalendarDateTime methods
Summary: Ref T10747. The CalendarDateTime object now carries the viewer timezone as part of its state, so we don't need to have separate accessors.

Test Plan:
  - Viewed events, checked that crumbs render properly.
  - Edited events.
  - Created new events.
  - Viewed calendar.
  - Viewed event detail pages.
  - Viewed profile mini-calendar.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T10747

Differential Revision: https://secure.phabricator.com/D16662
2016-10-06 03:52:30 -07:00
epriestley
e042533375 Store "start", "end", and "until" event dates as CalendarDateTime objects
Summary:
Ref T10747. This does double-writes and starts generating/writing CalendarDateTimes.

This greater flexibility is necessary to support the full range of ICS-specifiable events, including "floating" events.

This doesn't do anything yet.

Test Plan: Created and edited events, verified sensible representations of corresponding datetimes appeared in the database.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T10747

Differential Revision: https://secure.phabricator.com/D16661
2016-10-06 03:51:57 -07:00
epriestley
0ce7eacaf1 Introduce Calendar "UTC Epoch" columns for query windowing
Summary:
Ref T10747. Currently, Calendar events are mostly epoch-based and cheat a little bit for all-day events.

This already felt a little flimsy, and can't reasonably accommodate the full range of `.ics` events, which include "floating" events (e.g., occurs at 3PM regardless of timezone, like "Tea Time").

As a secondary issue, we identify instances of a recurring event by instance number (1, 2, 3, etc.). This can't accommodate the full range of `.ics` events, which include arbitrary additional "RDATE" events (e.g., recurrs every week, and also on these specific extra days).

However, we do need to store some epoch information so we can do query windowing: when the user looks at "October 2016", we want to select the smallest number of events that we can from the database initially, before refining them down to generate instances. We can't reasonably query the actual dates no matter how we store them because this depends on computing things like UNTIL, COUNT, initial dates, whether events are recurring or not, timezones, etc.

Instead, when we save an event compute the earliest second it occurs on in UTC and the latest second it occurs on in UTC. We can then query for a small superset of possible events in "October 2016" for any viewer pretty easily.

Also, start laying the groundwork for using fewer epochs in the rest of the code, and for reducing the role of sequence indexes (I plan to keep some sequences indexes around, probably, since they're nice in the UI, but not all child events will have indexes since there's no index for an RDATE event).

This doesn't migrate existing events yet or actually read these new columns -- that will come later once the new code is a little more solid.

Test Plan:
  - Ran `bin/storage upgrade`.
  - Created a new event.
  - Saved an existing event.
  - Viewed database, saw sensible-looking "UTC Epoch" values.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T10747

Differential Revision: https://secure.phabricator.com/D16652
2016-10-06 03:46:03 -07:00
epriestley
3d6c3c2c45 Make .ics export less scary and attach .ics files to event mail
Summary:
Ref T10747.

  - Remove the warning dialog since these files don't seem to do anything confusing/problematic in Calendar.app or Google Calendar. Those importers generally need to be defensive about how they handle random ".ics" files from arbitrary third parties anyway, and this makes testing imports easier since we have a GET-table ".ics" URI for public events.
  - Attach ".ics" files to email.

Test Plan:
  - Clicked "Export as .ics", got an ICS file.
  - Used "bin/mail show-outbound" to review an ICS attachment, although I don't actually have real mail set up locally so this may still be a little funky.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T10747

Differential Revision: https://secure.phabricator.com/D16559
2016-09-15 10:33:17 -07:00
epriestley
96f800249b Export ORGANIZER and ATTENDEE sections in ".ics" files from Calendar
Summary: Ref T10747. This exports these sections when generating an ".ics" file.

Test Plan: {F1832214}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T10747

Differential Revision: https://secure.phabricator.com/D16558
2016-09-15 08:48:23 -07:00
epriestley
47debbd57c Add an "Export as .ics" action to Calendar events
Summary: Ref T10747. Allows you to grab an event as a (basic) ICS file.

Test Plan:
  - Exported a normal event.
  - Exported an all-day event.

{F1830577}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T10747

Differential Revision: https://secure.phabricator.com/D16553
2016-09-14 19:07:52 -07:00
epriestley
25bd14a9b1 Respect "End Date" for recurring Calendar events in detail UI
Summary:
Fixes T11396. Currently, you can keep clicking "Next >" forever to generate infinite instances of an event, even if it has a set end date.

Likewise, you can visit `/E123/999999` or whatever to stub out the 999999th instance of an event.

Instead:

  - Before creating a new stub, make sure it happens before any end date.
  - 404 stubs if we can't create them.
  - Disable the "Next >" button if it isn't valid.

Test Plan:
  - Visited `/E123/9999` for an event with a recurrence end date, got 404.
  - Clicked "Next >" on an event with an end date, got new events until I hit the end date.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T11396

Differential Revision: https://secure.phabricator.com/D16517
2016-09-08 10:20:04 -07:00
epriestley
2e41c85cc9 Clean up recurring event information on Calendar events
Summary: Ref T11326. This adds prev/next links for recurring events (ala D16179) and moves the "accept/decline" buttons closer to the invite list. This might need some fiddling, but should be a little more human-friendly.

Test Plan: {F1740541}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T11326

Differential Revision: https://secure.phabricator.com/D16339
2016-07-28 10:59:28 -07:00
epriestley
b6c3d184d2 Make Calendar month view events render a little more consistently
Summary:
Ref T11326. This just inches things forward a little bit:

  - Make it easier to see current day.
  - Line-through cancelled events.
  - Don't colorize the whole event title, just use an Attending/Invited/Custom icon.
  - Slightly subtler treatment for all-day events.

Test Plan: See screenshot in T11326.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T11326

Differential Revision: https://secure.phabricator.com/D16306
2016-07-15 13:24:54 -07:00
epriestley
e2b6912b9d Store "All Day" events in a way that is compatible with EditEngine
Summary:
Ref T11326. Normally, events occur at a specific epoch, independent of the viewer. For example, if we're having a meeting in 35 hours, every user who looks at the event will see that it starts 35 hours from now.

But when an event is "All Day", the start time and end time depend on the //viewer//. A day like "Christmas" does not start at the same time for everyone: it starts sooner if you're in a more-eastern timezone. Baiscally, an event on "July 15th" starts whenever "July 15th" starts for whoever is looking at it.

Previously, we stored these events by using the western-most and eastern-most timezones as the start and end times (the earliest possible start and latest possible end).

This worked OK, but we get into a bunch of trouble with EditEngine, mostly because each field can be updated individually now. We can't easily tell if an event is all-day or not when reading or updating the start time and end time, and making that easier would introduce a huge amount of complexity.

Instead, when we update the start or end time, we write //two// times:

  - The epoch timestamp of the time the user entered, which is the start time we will use if the event is a normal event.
  - The epoch timestamp of 12:00 AM in UTC on the same date as the //local// date the user entered. This is pretty much like just storing the date the user actually typed. This is what w'ell use if the event is an all-day event.

Then, no matter whether the event is later made all-day or not, we have all the information we need to display it correctly.

Test Plan:
  - Created and edited all-day events.
  - Migrated existing all-day events, which appeared to survive without problems. (Note that events all-day which were created or edited in the last couple of days `master` won't survive this mutation correctly and will need to be fixed.)
  - Created and edited normal, recurring, and recurring all-day events.
  - Swapped back to `stable`, created an event, specifically migrated it forward, made sure it survived with times intact.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T11326

Differential Revision: https://secure.phabricator.com/D16305
2016-07-15 12:24:01 -07:00
epriestley
2ce37034ad Move event host and times into event subheader
Summary:
Ref T11326. Show this information with a subheader instead of in properties.

Also, slightly simplify the list view.

Test Plan: {F1723539}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T11326

Differential Revision: https://secure.phabricator.com/D16298
2016-07-14 07:50:20 -07:00
epriestley
6eaa9faec7 Provide default view and edit policies in Calendar, plus "Event Host" and "Event Invitees"
Summary:
Fixes T9224. This adds:

  - A "Default Edit Policy" and "Default View Policy" to Calendar, similar to other applications.
  - "Event Host" and "Event Invitees" objects policies.

These policies often end up being redundant (the host can always view/edit, the invitees can always view), but they can be more clear than setting "No One", and "Editable By: Event Invitees" is a legitimately useful policy.

Test Plan:
  - Created and edited events.
  - Fiddled with defaults.
  - Tried to remove myself as the event host for an "Editable By: Host" event, got an error ("you wouldn't be able to edit").
  - Tried to remove myself as host/invitee for an "Editable By: Invitees" event, got an error.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9224

Differential Revision: https://secure.phabricator.com/D16294
2016-07-13 15:42:12 -07:00
epriestley
439af11e70 Make event hosts editable
Summary:
Fixes T10909. I think this is a generally reasonable sort of capability to expose, although I've made it edit-only for now (when creating an event, you're always the host).

Also clean up some minor leftovers in the code, and a couple of little bugs with recurrence frequencies.

Test Plan: Created an event, edited the host of an event.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T10909

Differential Revision: https://secure.phabricator.com/D16292
2016-07-13 15:40:41 -07:00
epriestley
b6daa049de Rename Event "userPHID" to "hostPHID"
Summary: Ref T10909. Ref T9224. We label this field "Host" in the UI; make the storage format consistent.

Test Plan:
  - Viewed month view, day view, detail view of an event.
  - Created a new event, saw myself as the host.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9224, T10909

Differential Revision: https://secure.phabricator.com/D16291
2016-07-13 15:39:55 -07:00
epriestley
8ade91486c Add calendar.event.search and calendar.event.edit
Summary: Ref T7944. The search method is a bit bare-bones for now, but these substantially work.

Test Plan: Edited events via API; queried events via API.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T7944

Differential Revision: https://secure.phabricator.com/D16288
2016-07-13 10:17:46 -07:00
epriestley
7b09f5698f Convert Calendar to Modular Transactions
Summary:
Ref T9275. Swaps Calendar over to modular transactions. Theoretically, this has almost no effect on anything.

Ref T10633. I didn't actually do anything here yet, but this gets us ready to put timestamps in email.

Test Plan: Created and edited a bunch of events, nothing seemed catastrophically broken.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9275, T10633

Differential Revision: https://secure.phabricator.com/D16286
2016-07-13 07:46:33 -07:00
epriestley
46cf189413 Fix some EditEngine issues with rendering "invite" transactions
Summary:
Ref T9275. We were rendering too many transactions and/or over-rendering invitees.

Clean this logic up a bit:

  - List all before/after invitees.
  - Simplify the lists before rendering.

Test Plan: Viewed an event, edited invitees, got sensible human-readable transactions.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9275

Differential Revision: https://secure.phabricator.com/D16284
2016-07-13 07:45:35 -07:00
epriestley
a46a4362db Smooth over a few more transaction compatibility/structure issues with Calendar events
Summary: Ref T9275. This gets things roughly into shape for a cutover to EditEngine, mostly by fixing some problems with "recurrence end date" not being nullable while editing events.

Test Plan: Edited events with EditPro controller, nothing was obviously broken.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9275

Differential Revision: https://secure.phabricator.com/D16282
2016-07-13 07:44:15 -07:00
epriestley
bac6acb3d1 Make EditEngine form for Calendar Events almost fully-functional
Summary:
Ref T9275. This still has a number of rough edges and other minor problems (no JS on the controls, some date handling control bugs) but I'll smooth those over in future changes.

It does make all the editable transaction types available from EditEngine, technically speaking.

Test Plan: Created and edited events with the "pro" controller, which mostly worked.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9275

Differential Revision: https://secure.phabricator.com/D16281
2016-07-13 07:43:38 -07:00
epriestley
eebaf58342 Simplify the TYPE_INVITE Calendar Event transaction for EditEngine
Summary:
Ref T9275. Now that TYPE_ACCEPT and TYPE_DECLINE have been separated out, we can simplify TYPE_INVITE.

This now just takes a list of invited PHIDs, uninvites ones that were removed and invites ones that were added. This is simpler, lets more logic live in the Editor, and makes EditEngine/API access easier.

Test Plan: Created events, added and removed invitees. Used comment stacked action and "pro" editor to adjust invitees.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9275

Differential Revision: https://secure.phabricator.com/D16280
2016-07-13 07:43:06 -07:00
epriestley
c09e870733 Prepare event dates for EditEngine/API
Summary:
Ref T9275. Currently, the "Start Date", "End Date", and "Recurrence End Date" transcations take a complex value (AphrontFormDateControlValue) and reduce it to an epoch.

Do this a little earlier, since the API will be much more usable if it just passes in epoch timestamps.

Events also have some logic where they rewrite the from date and to date on the actual object for all day events, then undo the changes later. Specifically, if you have an all-day event on "July 24th", the exact start and end times vary based on who is looking at it. Instead of overwriting the persistent `dateFrom` and `dateTo` properties, add separate `viewer` properties to make it easier to keep this stuff straight.

Since this means all-day events get stored in UTC, we need to query/fetch (and then discard) slightly more events. This is perfectly and much simpler to do.

The one weird "UTC" hack in here will get nuked when this moves to EditEngine properly.

Test Plan: Edited times for normal events and all-day events.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9275

Differential Revision: https://secure.phabricator.com/D16274
2016-07-13 07:42:30 -07:00
epriestley
3a09bb577e Create separate "Accept" and "Decline" transactions for Calendar
Summary:
Ref T9275. Currently, there's a single "invite" transaction type for managing Calendar invites, and it takes a map of invitees to status.

This isn't great for EditEngine or API access, since it lets you set anyone else to any status and we can't reuse as much code as we can with a simpler API.

Make "Accept" and "Decline" separate actions which affect the actor's invite, so "invite" can be a simpler transaction which just invites or uninvites people.

Test Plan:
  - Joined/accepted/declined an event invitation.
  - Edited event invitees.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9275

Differential Revision: https://secure.phabricator.com/D16272
2016-07-13 07:41:58 -07:00
epriestley
ffdb9f06f8 Move more event fields to EditEngine
Summary:
Ref T9275. This moves description, icon, and cancel/uncancel to EditEngine.

It removes TYPE_SEQUENCE_INDEX and TYPE_INSTANCE_OF_EVENT. These are currently never generated and I do not expect to genereate them (instead, these changes happen automatically when you edit a stub).

Test Plan: Edited an event with normal and pro edit forms.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9275

Differential Revision: https://secure.phabricator.com/D16264
2016-07-13 07:41:34 -07:00
epriestley
3ab6a7e19f 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-13 07:41:16 -07:00
epriestley
8a98868bfb Remove "days fresh" / "days stale" indictator in Differential revision list
Summary:
Ref T10939. I'm not //totally// opposed to the existence of this element, but I think it's the kind of thing that would never make it upstream today. I think this should just be a T418 custom sort of thing in the long run, not a mainline upstream feature.

Overall, I think this thing is nearly useless and just adds visual clutter. My dashboard is about 100% red. This also sort of teaches users that it's fine to let revisions sit for a couple of days, which isn't what I'd like the UI to teach. Finally, removing it helps the UI feel a little less cluttered after the visually busy changes in D15926.

Test Plan: Grepped for removed config. Viewed revision list.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T10939

Differential Revision: https://secure.phabricator.com/D15927
2016-05-16 10:47:19 -07:00
epriestley
abb4c03b47 Remove shouldShowSubscribersProperty() from SubscribableInterface
Summary:
Every caller returns `true`. This was added a long time ago for Projects, but projects are no longer subscribable.

I don't anticipate needing this in the future.

Test Plan: Grepped for this method.

Reviewers: chad

Reviewed By: chad

Differential Revision: https://secure.phabricator.com/D15409
2016-03-06 06:01:36 -08:00