I am very sorry! please delete it.

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:

This self-healed (probably after another commit was pushed) so I don't expect to look at it for a while unless it happens again.

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• Sorry, I've dropped my bag of Doritos™ brand perfect circles • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • •• • • •• • • • • • • •

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.

So far the pup is sleeping a lot and doing very little mischief.

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

(mindrot.org is currently inaccessible for me so I wasn't able to read the details you linked, although I imagine they aren't too relevant to how we handle things.)

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

The rTRANSLATEWIKI repository is now available. Here is an example of the en.json MediaWiki-style JSON string file we currently generate:

This isn't a bug. Here's an example of why the proposed behavior is dangerous:

I'd prefer not to produce any output until we've generated everything, so we don't end up in a situation where we output half of the file and then fail if we can help it. Additionally, this script changed in D16744, a few weeks ahead of your version.

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.

I don't know what this means. $ in the string contents isn't anything special for translatewiki.net.

• When exporting, I don't know how to escape $ for Translatewiki (this affects ~10 strings).

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

Likewise, when importing, I don't know how to unescape $.

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

The technical definition of "Limited" is that it has fewer than 512 strings, including 0 strings.

In T5267#199144, @epriestley wrote:

• Did you notice that "Spanish (Spain)" was under the "Limited Translations" heading, instead of the "Translations" heading?

You should file a new bug report, describing exactly what you did and how we can reproduce the problem.

@epriestley where is the propper place then to help improving documentation?

To report a bug, please provide complete reproduction steps. We can't fix issues we can't reproduce. See Contributing Bug Reports for details.

I think D16810 should get this started, at least. Known technical issues:

@MZMcBride, couple of questions so we can improve this:

I've marked D16806 as resolving this. Once that lands, here's the state of the world in terms of how the product works:

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