(comment posted twice for some reason)

I thought I'd throw our use case in here in case it helps:

More generally, here's how I'm planning to model imports, which seems largely consistent with other systems:

Yeah, I fiddled with that but didn't immediately have any luck. It's possible that there's some complex condition like non-self organizer + non-self sender or something. If it only requires non-organizer, it should already work today (e.g., on this install).

Sort of. I'd like to have use cases (what are you trying to do?) first, and I'm not certain what the best representation of dates and times is for external consumption.

@epriestley: Are you open to patches that add more information to the calendar.event.search response? It currently does not even include the event time which is a pretty crucial detail to make the results useful.

@epriestley in that post you linked there's a comment:

I'm having trouble making GMail provide a reasonable pathway forward for getting .ics events onto Google Calendar. Ostensibly this just works:

ICS primarily identifies users (organizers and attendees) by email address. Phabricator does not normally disclose email addresses, and I don't want to let someone scrape every email address out of Phabricator by inviting every user to an event and downloading the .ics.

IMO, Pokémon catching is an essential feature, please implement that first.

Resolved by D16488.

Well, "trivial" might be a little ambitious.

Ah, thanks! That's a bug which we hadn't run into yet, but it's trivial to fix.

When tasks are mentioned in calendar descriptions (afaik very common for meeting agendas), the usual "<user> mentioned this in <place>" does not show up on the task. Is this part of the unprototyping effort?

I'm super excited about this feature.

Calendar is currently prioritized, but the scope is focused on basic functionality (getting it out of the "prototype" stage, roughly described in T11326 with more recent activity in T11326) and API integrations (Google Calendar in T2334, ICS in T10747).

I expect to do this eventually, but I'm hesitant to just put a freeform "Location" text field on events. If we do, we can't prevent double-booking physical meeting rooms, since users may spell physical space names differently and we can't know for sure that "Meeting 6", "Meeting Room 6", "Meting Rum Six", and "Meeting Room#6" are all the same.

See T7924 for current Calendar roadmap items.

So CalDAV support (for iCloud and others) is not planned? Google Calendar API is propritary while CalDAV is a standard. There is a really good php implementation of client/server and card parsers: https://github.com/fruux/sabre-dav
@devurandom yes that is true, and it is really simple using save/dav.

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.

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

Thanks :).

Maybe I shouldn't debug things before coffee. getChanges is fine, the problem is something else; I think the recorded information might be wrong.

Not a rendering bug, it's a translation: https://secure.phabricator.com/diffusion/P/browse/master/src/infrastructure/internationalization/translation/PhabricatorUSEnglishTranslation.php$1571

Mostly, that's because getChanges in PhabricatorCalendarEventInviteTransaction is wrong - the phids in this transaction are in keys, not values.

I think most of this is in reasonable shape now, at least for the moment.

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).

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

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

Use of link color to convey state is weird?

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

My test data is pretty sketchy:

got a full screenshot?

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

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