Summary: Ref T10747. This turns on the newer EditEngine behavior so we get a nice "X created this event." transaction, instead of an "X renamed this from <nothing> to Event Name."
Test Plan: Imported an event, saw a nice timeline.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10747
Differential Revision: https://secure.phabricator.com/D16771
Summary: Ref T10747. The transaction version of this copies the "all day" flag over properly, but this non-transaction version needs to copy it explicitly.
Test Plan: Imported an all-day event, saw it come in as all-day.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10747
Differential Revision: https://secure.phabricator.com/D16770
Summary: Ref T10747. If stuff has been deleted on the other calendar, delete it on ours.
Test Plan:
Imported with deletion, saw deletions:
{F1889689}
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10747
Differential Revision: https://secure.phabricator.com/D16768
Summary:
Ref T10747.
- Adds import documentation.
- Adds import/export docs to the help menu.
- Removes some weird/old/out-of-date information from the general user guide, which I'll rewrite later.
Test Plan: Read documentation somewhat thoroughly.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10747
Differential Revision: https://secure.phabricator.com/D16766
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
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
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
Summary: Fixes T11733. This fixes the issue by working around it, but it isn't useful to set these fields to a default value anyway.
Test Plan: Created a default Calendar form, set some other defaults, created an event, stuff no longer exploded.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T11733
Differential Revision: https://secure.phabricator.com/D16753
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
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
Summary: Ref T10747. This makes development/debugging/testing easier and moves us closer to triggered imports (e.g., keep in sync with Google once per day).
Test Plan:
- Reloaded an event import.
- Edited an event in Google Calendar, reloaded, got updated event.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10747
Differential Revision: https://secure.phabricator.com/D16747
Summary: Ref T10747. This doesn't have a "keep up to date" option yet, but can, e.g., fetch a Google Calendar URI
Test Plan: Fetched a Google Calendar URI, got some events imported.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10747
Differential Revision: https://secure.phabricator.com/D16730
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
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
Summary: Ref T10747. When viewing an import detail page, show a little more information about what you're looking at.
Test Plan: {F1876957}
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10747
Differential Revision: https://secure.phabricator.com/D16726
Summary: Ref T10747. Although I could possibly imagine some very selective cases where we do this eventually, these are read-only for now and not interesting to publish/mail about. The presumption is that the original/authoritative system has already notified relevant parties or they're subscribing passively.
Test Plan: Imported some name changes for events, saw no more mail/feed stuff.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10747
Differential Revision: https://secure.phabricator.com/D16723
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
Summary:
Ref T10747. When we hit an ICS parser error, render it into a log instead of fataling.
(This will be more important in the future with subscription-based URL ICS import.)
Test Plan: {F1875292}
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10747
Differential Revision: https://secure.phabricator.com/D16721
Summary:
Ref T10747. If you accidentally import the wrong thing, you can clean up the big mess you made.
These imported events are read-only so it's OK to destroy them completely (vs disable/hide/archive).
Test Plan: Destroyed some imported events.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10747
Differential Revision: https://secure.phabricator.com/D16720
Summary:
Ref T10747.
- Look at more than 25 logs!
- Review your favorite logs. Heartwarming! :)
Test Plan: Looked at logs. Wow! Logs!
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10747
Differential Revision: https://secure.phabricator.com/D16719
Summary: Ref T10747. Don't let users import SECONDLY events, or events outside of the range of a signed 32-bit integer (these are likely not too hard to support, but they're more headaches than we need right now).
Test Plan: Tried to import these no-good problem events, got helpful import errors.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10747
Differential Revision: https://secure.phabricator.com/D16716
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
Summary: Ref T10747. Show which events a source imported, and link to the full list as a query result.
Test Plan: {F1870049}
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10747
Differential Revision: https://secure.phabricator.com/D16703
Summary: Ref T10747. This doesn't do much for ICS file imports (you can't disable them since it doesn't do anything meaningful) but will matter more for ICS-subscription imports later.
Test Plan: Clicked "Disable" on an ICS file import, got explanatory dialog.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10747
Differential Revision: https://secure.phabricator.com/D16702
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
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
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
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
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
Summary: Fixes T11745. I just missed this while juggling some of the internal storage.
Test Plan: Created a new event with recurrence behavior.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T11745
Differential Revision: https://secure.phabricator.com/D16684
Summary:
Ref T10747. This adds disable/enable to exports.
Mostly useful if you leak a URI by accident.
Test Plan:
- Disabled and enabled exports.
- Verified that disabled exports don't actually export any data.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10747
Differential Revision: https://secure.phabricator.com/D16681
Summary:
Ref T10747. This explains how exports work.
Also make mail exports use the same logic as other stuff.
Test Plan: Read documentation. Did some exports.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10747
Differential Revision: https://secure.phabricator.com/D16680
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
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
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
Summary:
Ref T11326. This reorders sections:
- Description (if present)
- Recurring event series info (if recurring)
- Invitees (this also has custom stuff, if it exists)
Test Plan: Viewed some events, saw more sensible order.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T11326
Differential Revision: https://secure.phabricator.com/D16671
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
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
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
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
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
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
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
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
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
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
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
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
Summary:
* Fixed conveted => converted
Ref T11576
Test Plan: * Looked at a page, where somebody converted an AllDay Event to a normal one
Reviewers: #blessed_reviewers, epriestley
Reviewed By: #blessed_reviewers, epriestley
Subscribers: epriestley
Tags: #calendar
Maniphest Tasks: T11576
Differential Revision: https://secure.phabricator.com/D16488
Summary:
Ref T7924. This:
- Adds support for remarkup block changes to Modular Transactions.
- Exposes remarkup changes from the Calendar event "Description" transaction.
This makes stuff like mentions and file embeds work properly.
Test Plan:
Mentioned a task in an event description, saw a mention appear on the task.
Uploaded a file to an event description, saw the file become "Attached" to the event.
(Neither of these worked properly before.)
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T7924
Differential Revision: https://secure.phabricator.com/D16481
