1
0
Fork 0
mirror of https://we.phorge.it/source/phorge.git synced 2024-12-18 11:30:55 +01:00
Commit graph

15 commits

Author SHA1 Message Date
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
72edd36c7a Fix an issue with recurrence rules being set improperly in transaction code
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
2016-10-07 08:07:57 -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
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
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
Luke081515
0eb5a80e7b Fix typo at calendar transaction
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
2016-09-02 06:18:17 -07:00
epriestley
27cfd8d19e Support object mentions in Calendar Event descriptions
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
2016-08-31 15:33:45 -07:00
Aviv Eyal
b6bf0f6a3b Re-implement calendar.invite transactions
Summary:
Fix T11339.
Now, old and new are both simple lists of phids, and the rendering should make sense.

Test Plan: Viewed existing transaction with all 3 states.

Reviewers: epriestley, #blessed_reviewers

Reviewed By: epriestley, #blessed_reviewers

Subscribers: Korvin

Maniphest Tasks: T11339

Differential Revision: https://secure.phabricator.com/D16311
2016-07-22 18:03:28 +00: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
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
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