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

Cool. I'll merge this into T4124 and retitle that to be a little more specific.

I'm quite certain that it's the -L option. Let me talk to the system administrator about installing the GNU diffutils -- I'm guessing that it won't be a problem.

We've only seen that one other time, so it hasn't been a priority to fix. I believe the other install which hit the issue was able to install GNU diff to resolve it.

Yes, I think that it's the same issue as T4124: Test the capabilities of `diff` better, especially for Solaris, as I just found the -L options in generateRawDiffFromFileContent.

Incidentally, this Phabricator installation is running on Solaris (Solaris 11.3) if that makes any difference.

Thanks for the quick feedback. Perhaps it's something unique to my environment because I can reproduce this behavior consistently across multiple repositories.

(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 {rP3f2f81a1c8ab6ccb99caa01b7fd12b928ed30eba} 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.

These shards are now in service.

Provisioning completed, now deploying.

Starting this now.

2. Why is there a 2 in the middle of all that? https://xkcd.com/1530/

As a user of both Phabricator and Mercurial, opening up HTTP isn't an option we want to consider and would instead stick to having the repository hosted elsewhere.

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.

If it helps anyone, I've been using this extension to allow exporting tasks with custom fields as well as the workboard column. Please read the comment at the top of it for full details:

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

Today, we already decode the SSH wire protocol and figure out what's going on inside it up to the bundle2 stuff -- here's the, uh, "protocol spec":

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:

It should be possible to determine whether an operation is read or write by the command name: a command either performs writes or it doesn't. The only write commands you should see are unbundle and pushkey. While it might be possible for batch to contain pushkey operations, I don't think that's done today (but I'd have to audit the code to be sure). One thing you should be able to rely on is the HTTP method: GET requests should never perform any significant writes (although some cache files may be written to as a result of resolving data, but that shouldn't be important). It should be perfectly valid to treat GET and POST differently. Although if you route requests to different endpoints within the same TCP/HTTP stream, inconsistent state of a read-only mirror from a master could lead to race conditions (e.g. push fails because a mirror is out of sync). If you route by HTTP request method, you should not need to know anything about the Mercurial wire protocol.

There's also a 6

I've rotated the certificates on lb, alb, and notify. One minor notify issue that I'll file separately.

Two questions come to mind.

As a workaround, the recommended value is 9999999999999999999999999999999999996999999999999999999999929999999999999.

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.

I can't reproduce this by following the steps provided. Here's what I did:

Just encountered this problem on my setup too.

This appears to legitimately be fixed, now.

I finally got this reproducing locally, at least.