Month view in desktop mode should be flush with box?

This one's sort of tricky because the padding is coming from the search result view, so I'm going to circle back to it.

I'll get you an update month view here this afternoon, I've been mulling it over.

I poked at it a little bit but only got this far:

got a full screenshot?

My test data is pretty sketchy:

I'll CSS in the event details later, but wanted this to go full width if possible.

Use of link color to convey state is weird?

Yeah, I think so. If I declined something, just remove it?

Visually, I have a hard time picking out the current day/week.

{$sky} looks fine to me if that what you're using.

I'll have my laptop with me next week, should be easy for me to clean up CSS stuff on the road.

I spent pretty much the whole afternoon yesterday getting "All Day" events working properly without getting a result I was happy with (some of this was untangling date controls, which will probably come upstream eventually).

One of the major issues is that API calls or custom edit forms may change "All Day" without changing the Start Date / End Date, or even having them present on the form, and we may get a series of transactions like "change start date, set all day, change end date, clear all day". Currently, the way that some of these transactions should be interpreted depends on the existence and values of the other ones, but the code to interpret the transaction happens way before we start applying changes.

We generally don't have transactions that work like this, and largely for good reason -- it makes things much more complex if the behavior of a transaction depends on the state of other transactions.

I gave up and slept on it and I think I have a better approach now, which is basically:

• Store normal start date, normal end date, all-day start date (UTC 00:00) and all-day end date (UTC 11:59:59) on all events, whether they are all-day or not.
• When start/end are updated, update both the normal and all-day fields.
• When working with events, ignore the normal fields for all-day events, and the all-day fields for normal events.

Then all the edit operations should be straightforward, all the zone mangling is hidden in the Editor, and we don't need any weird client timezone magic.

land what you got and I can start fiddling? or did you have more?

I think you're free to fiddle -- there are some more adjustments and things, but nothing too significant. I think the only other really CSS-ish thing is that if you search for events in a specific range (July 5-7) on a calendar view, I'd like to make it clear which days your query covers.

I think I'm going to move the recurrence controls to a separate screen, so you'll make a recurring event in two parts:

• First, create an event.
• Then, select "Make Recurring" or "Edit Recurrence Rules" or something like that from the action menu.

That will pop up a dialog with the "Repeat Every: [Week]" and "Repeat Until: [X Date]" controls.

This will simplify creation and give us room to render a more complex static element for RRULE/ICS events or expose a more powerful control later (e.g., show you all the details of an ICS RRULE, or let you actually specify "every 3rd thursday in June and July" some day).

I think this is fairly similar to Google Calendar and Calendar.app, which both show you event creation first and require you to click something to access recurrence behaviors. I think defining recurring events is also rare enough that it's generally reasonable to put on a secondary workflow, regardless of what other applications are doing (they just also happen to be doing this, in this case).

Nice idea! Also would be good to flip Description / Invitees boxes on the view page.

Yeah, agreed.

Rough overall state of the world is that "all the hard stuff" is mostly "done" but it's probably fairly buggy, so I'm going to push on exports and some UI stuff for a bit and try to catch all those bugs while I do. Also imports are probably hard but I'm going to imagine that they aren't for now.

I'm a little worried that the migration in D16664 might do horrible things that I missed because all my test data is goofy, too, but it's hard to test that really convincingly. I left all the old data around so we should be able to repair stuff in the worst case, but it may be messy.

Here's what I'm planning to do for imports:

• Like export sources, import sources are bound to a particular user.
• Imported events are read-only (we could eventually relax this in some ways, maybe).
• When two users import the same event (same UID) we make two copies of it in the system.
• If two or more copies of an event are visible to you, we show you only one:
  • the one you imported, if one exists; or
  • the oldest one, if one does not.

Policy-wise, I think this should be true, per read-only-ness and simplicity:

• All events imported from a given source have the same visibility.

I'm not sure what the policy associated with an import source should be, though. Some possibilities are:

1. All import sources are personal.
2. "Policy Mode" choice like exports (roughly: public, private).
3. Full policy selector.

I think (1) probably prevents reasonable use cases (like bringing team/group calendars defined elsewhere into Phabricator), and (2) isn't powerful enough for some reasonable use cases (bringing a group calendar in but keeping it local to a particular group). However, (3) might make querying very inefficient in the long run, as we'll potentially need to filter out a very large number of private recurring events that users have imported, and won't be able to do this especially cheaply. Still, we can probably make the common cases of this cheap enough.