In T11809#199051, @deric wrote:

The rP3f2f81a1c8ab: Remove obsolete Calendar event date storage fields commit broke our phabricator setup.

#1054: Unknown column 'event.dateTo' in 'where clause' at [<phutil>/src/aphront/storage/connection/mysql/AphrontBaseMySQLDatabaseConnection.php:325]
PHP message: arcanist(head=master, ref.master=fad85844314b), phabricator(head=master, ref.master=bd3233d3ab0c), phutil(head=master, ref.master=e409df2720c2)
...

for fixing seems to be enough:

use phabricator_calendar;
alter table calendar_event add dateTo int unsigned NOT NULL;
alter table calendar_event add dateFrom int unsigned NOT NULL;

• D16877 includes the entire CLDR "windows to the rest of the world" map in things we'll recognize.
  • Neither that map or the Microsoft map have "Russian Time", but maybe that's just what the UI shows for zones like "Russia Time Zone 10", and not what actually appears in the ICS file? Otherwise we're going to have to keep digging.
• D16878 fixes the form customization stuff I mentioned above, mostly by preventing quirky/confusing fields from being customized (at least, for now).
• D16879 fixes a rendering bug with "All Day" events that could shift them forward or backwards by a day.
• D16880 uses the same rendering logic for subheaders (which now appears to be correct) and tooltips (which had a different, older copy of very similar logic).

• Editing the EditEngine default form and removing "Host" means that "Host" no longer prefills. This is the same as T10222. A temporary workaround would be to prevent that field from being defaulted. It should be defaultable in the long run, but is probably low-value to assign a default to, so it's probably better to just lock it for now and make it behave a little more sensibly.

Some other stuff:

It's my fault - I edited the comment to add that link (probably based on
the same search you did) in parallel with your reply.

Whoops... just read your full comment. Sorry for dupe.

Is this the complete list?

Unfortunately "W. Europe Standard Time" is just one of the many unnecessarily verbose timezone names that Microsoft uses. I also had "Singapore Standard Time" and "Russian Time" (which I presume refers to Moscow, rather than any of the other dozen or so timezones in Russia) in my calendar for this week.

• D16866 is just what I needed, thanks!
• D16867 fixes what I reported, but I hadn't noticed that the month view tooltips are also affected in the same way:
  

• D16865 should treat "W. Europe Standard Time" as "Europe/Berlin". We'll figure out some better solution for this if it continues being an issue, I'm just still hopeful that we can get almost-correct coverage with a handful of explicit mappings/rules without needing to do anything more complicated.
• D16866 should give the datepicker more reasonable behavior on mobile/tablet devices (the panel should now center on screen when activated).
• D16867 should fix the issue with all-day events sometimes extending too far in the summary text on the day view.
• D16868 improves behaviors around inviting projects to events on the day/month/detail views.
• D16870 makes a query for "Invited: epriestley" mean "events which epriestley is invited to, or any project that epriestley is a member of is invited to". You can find just individual invites with "Invited: exact(epriestley)".

The implementation effort required to support arbitrary VTIMEZONE entries would be fairly huge, since we'd need to reimplement the PHP builtin classes DateTime and DateTimeZone and basically write a full date handling engine. I believe there is no compelling reason for software to ever specify an event in a timezone which is not part of timezonedb (I believe timezonedb is accurate, exhaustive, and fairly ubiquitous; and RFC5545 mentions it, although it does not require it be used), although mapping VTIMEZONE names to timezonedb names may be difficult.

ICS import does not seem to parse VTIMEZONE entries in the ICS file. This is perhaps related to the Zimbra issues above, though in my case I am importing from outlook.office365.com. The ics contents include:

When creating an event, the date picker may be drawn partly off the screen:

• LGTM, thanks.
• That icon makes sense now that I know what it indicates. I doubt that there's a universal icon for this particular purpose. Maybe something like (or the open version added in the newest FA), but that's still unclear if you don't already know what it means.
• That's reasonable.
• I created the all day event E1211 to span the 14th and 15th (see image below). It appears correctly in the month view, but the event page says:

• D16852 should fix the coloring on the mobile month view.
• The icon means you're invited, not that other users have joined the event. Could we pick an icon that you'd find more clear? (Available Icons).
• Old events have undergone several migrations and probably aren't unambiguously fixable at this point, so I don't expect to correct any remaining migration issues.
• I can't reproduce the last issue you describe ("but are extended forward by a day on the event page"). Can you provide specific reproduction instructions?

Thank you for giving Calendar some attention! Looking forward to it becoming a proper grown-up application.

Thanks for looking into the profile. The queuing I think fixes the issue with speed of importing. The next thing I was going to try was auto-import of the .ics file from a hosted location on hourly basis, and I'm assuming there's no proper way to only query for the newest things (at least though the API in Zimbra I've found) - so Phabricator would have to process the file every request. With queuing it shouldn't matter.

Here's the XHProf link:

The color should be fixed by D16819.

@epriestley nope, as you can see in my last screenshot the Nov 8 event doesn't have any edits in the transaction log. We don't use any third-party app to edit the calendar, just the Phabricator UI.

At HEAD, I think the all-day issues with the French holidays above are fixed. You may need to reload the import for the change to take effect, but things seem OK for me locally now:

Ah, cool. I think that's a Zimbra issue, then.

@ivo, that's expected if you previously edited the Nov 8 instance. This is consistent with Calendar.app, although not with Google Calendar.

I checked for that UID and there are exactly two events, both with "RECURRENCE-ID":

RECURRENCE-ID;TZID="America/New_York":20130528T150000

I was trying to import the french holidays from google ICS file...

Thank you for clarifying the behavior of the timeout. It wasn't clear to me whether I would wait for feedback after clicking the Reload button or begin refreshing the page. After the change to queuing of import the events were imported. I'm doing all this testing on a test instance of Phabricator so I would be able to add log/debug statements and re-import the calendar again to track down what might be slow. The import pulled in ~1700 events in ~3 minutes.

When changing the start and end dates on all future instances of an event, some of the future instances may keep the old dates.

I was trying to import the french holidays from google ICS file : https://calendar.google.com/calendar/ical/fr.french%23holiday%40group.v.calendar.google.com/public/basic.ics

I would expect that we could parse a 3MB .ics file in less than 30 seconds, but obviously there's nothing to prevent you from uploading a 30MB or 300MB or 3GB .ics file, and at some point we'll take longer than 30 seconds to process it.

I tried reloading the import again and still hit the 30 second timeout. There's no indication in the web page UI that anything happens but I checked the logs. Is this just expected for a large import?

T11399 has some discussion of "Location" for events -- we could possibly implement a little piece of that now to split out resources from normal attendees, but my initial inclination is to wait until we do a real implementation of locations.

If a user has a display name ("Meeting Room" <meetingroom@company.com>), we should show them as "Meeting Room", we just avoid showing meetingroom@company.com if that's the only name we have.

I think this is good default behavior and what I was expecting regarding not showing email address. My earlier comment was more about whether it could be shown as a Resource instead of an attendee (due to CUTYPE=RESOURCE;ROLE=NON-PARTICIPANT), or possibly the Location as the email matches what the LOCATION field is set as -- instead of "Private User" invitee. This sounds more like a new feature request and not a bug/issue - should I make a separate task?

I wasn't immediately able to reproduce the "OPT-PARTICIPANT" issue -- here's the file I used, trying to mimic your test case:

• D16804 should resolve the sha1() issue.
  • That may also resolve the timeout: the sha1() issue made us take a much slower code path. But I might also need to optimize the import and make it fall back to occurring in the background for large .ics files. Let me know if you're still seeing timeouts after the sha1() fix.
  • When a user is only an email address, we currently show "Private User 1" instead of the address. We could just show the address, or could show some "totally impossible to guess" address like me.......om@mycompany.com, but I wanted to err on the side of caution about disclosing email addresses, at least to start with. We're fairly conservative about this in other parts of the product and it's hard to put the cat back in the bag if we consider this information open. In Phabricator, it's easier to import an .ics file and expose the data to all users than it is in more private-by-default / personally-focused applications with defaults aimed more toward individual users, which also gives me some pause. But this may get in the way of usability too much, so I could see changing this behavior. If a user has a display name ("Meeting Room" <meetingroom@company.com>), we should show them as "Meeting Room", we just avoid showing meetingroom@company.com if that's the only name we have.
  • I'll look at the OPT-PARTICIPANT thing, I would expect them to import but just not have an "optional" marker right now. To clarify, they didn't import at all, right?
  • The "Ignored Node" stuff is likely fine, things like VALARM sections inside VEVENT sections. At some point I'll make the error message more helpful ("Ignored a VALARM section; Phabricator does not send reminders for imported events.") but probably OK to ignore those warnings for now.
  • URI stuff is because security.outbound-blacklist defaults to blacklisting all private/internal IP space, to prevent attackers from discovering and interacting with private services on your network by using features like image proxying, macros, calendar import, etc. If you want to fetch data from a host in private IP space, you'll need to remove its address from the blacklist (or expose an alternate interface for it in public IP space).

(If you believe I'm mistaken, please show the full stack trace for the error so we can identify and remove the remaining reference to this column.)

@deric, the code event.dateTo no longer appears anywhere in Phabricator (it was removed prior to the column being removed) so I suspect you did not restart properly and were running cached code (or possibly have custom code you need to update). See Restarting Phabricator.

The rP3f2f81a1c8ab: Remove obsolete Calendar event date storage fields commit broke our phabricator setup.

#1054: Unknown column 'event.dateTo' in 'where clause' at [<phutil>/src/aphront/storage/connection/mysql/AphrontBaseMySQLDatabaseConnection.php:325]
PHP message: arcanist(head=master, ref.master=fad85844314b), phabricator(head=master, ref.master=bd3233d3ab0c), phutil(head=master, ref.master=e409df2720c2)
...

for fixing seems to be enough:

use phabricator_calendar;
alter table calendar_event add dateTo int unsigned NOT NULL;
alter table calendar_event add dateFrom int unsigned NOT NULL;

(Moved from T11816#199040)

Oh shoot I just saw your changelog note about reporting import/export issues on T11801. Sorry. Keep here or migrate comment?

In my head all this email RSVP did sound noodley and would need more definition before it could go into a version. I figured I would mention it to see if it was even considered and/or you'd like tasks for use cases/definitions.

• D16803 should fix Applications → Calendar → Edit Policies.
• D16800 + D16801 should fix fanciful timezones present in ICS files.
• D16802 should add the ability to select a greater or lesser degree of away-ness for each event.

In my company, other then personal calendars, we have a small number of shared (google) calendars, which might be relevant use-cases:

• Out of Office Calendar: Each person is expected to add their OOO/WFH-ness there, so everybody has a quick-glance view of who's around. The only way to differentiate "available online" or not and who is effected is by actually reading the items, but that's a technicality.
• Release calendar, where we list dates/times of code freezes, test cycles, deployments, planed external outages, etc.. This one works much better, mostly because it has a lot less events on.

I think I'd like to see the red dot being more lenient/controlled. For example, if I'm in a meeting, it should probably not show me the same level of "away-ness" as a week's vacation; Similarly, if I put an event on my calendar for "Work-from-home" or "No meetings day", I might be more available than normally.

Ok - it looks like running through the upgrade process to master again likely resolved the schema issues I had~

I think this would be a new feature request altogether for the calendar events, but it looks like they aren't interoperable with email. I'm guessing this is intentional for the first version or so of calendar so as to not widen the scope of the project as well as from a security standpoint to avoid leaking emails.

Yeah, test on master -- there's a ton of stuff fixed there that's still broken on stable.

For users testing would you prefer we go based of master instead of stable? If so I'll have to figure out why the upgrade stuff wasn't working. However from the same instance above:

Sorry, not clicking "Config". It was clicking "Edit Policies" after clicking "Config"

I got this exception after turning on Calendar and clicking "Config" for the application:

I'm just going to WONTFIX this for now since Maniphest and Differential don't show descriptions either and it's not clear to me that event descriptions are significantly more valuable than task/revision/etc descriptions. Open to changing this, but we should either change it everywhere or have some consistent rule for when they do/don't show.

This appears to legitimately be fixed, now.