I can't reproduce this locally and I'm not really sure what's up (bad/weird import, maybe? But no issues importing the same source locally), so I'm just going to cheat my way through it at least for the moment.

Here's the trace:

I'm specifically interested in the arc diff --try part of this and would want that to be the configurable as the default behavior. For an installation that's using things like CircleCI integration to run tests asynchronously on a build server, it seems very plausible that reviewers will sometimes fail to notice that tests haven't finished running yet, which will lead to people landing broken code.

These are very much proof-of-concept for now, but should technically work after D16784. Expected behavior now:

Also interested in this. Our team plans on using the audit tool for code reviews, it be good if when a developer has made any suggested changes and re-committed that the old open audit could be closed/linked to the latest commit rather than having to comment on the old one with a link to the changed copy and just closing the old one manually.

Could phabricator.base-uri setting affect this? Our install is accessed via http://phab.domain.com:port/.

It may surprise us how much people use it.

I guess we're just accepting Calendar bugs in general now since I don't have a ton of known broken stuff left on my radar. I was aware of this one; D16777 should fix it.

I got 12 quest points. Level up!

I plan to start working on new comment/action UI here this week. Probably. Maybe.

Please be sure to update Phabricator before filing a bug report.

@rabahmeradi So it was, shortly afer reporting! Thanks.

Our users can confirm this behavior. With active persistent chat, the Lightbox is not working. If it is disabled, its working as expected.

Our users can confirm this behavior. With active persistent chat, the Lightbox is not working. If it is disabled, its working as expected.

In T11801#198622, @adam93 wrote:

Mentioned in chat but just to keep it logged. Importing an ics file with the following RRULE (RRULE:FREQ=WEEKLY;BYDAY=TH;INTERVAL=2) works as expected opening in Microsoft Outlook, but gives the following error in Phabricator upon import "RRULE INTERVAL "2" is invalid: interval must be an integer."

As @epriestley said in the general chat "We're missing an (int) cast in PhutilRecurrenceRule::newFromRRULE() on INTERVAL and probably COUNT".

Mentioned in chat but just to keep it logged. Importing an ics file with the following RRULE (RRULE:FREQ=WEEKLY;BYDAY=TH;INTERVAL=2) works as expected opening in Microsoft Outlook, but gives the following error in Phabricator upon import "RRULE INTERVAL "2" is invalid: interval must be an integer."

@indygreg - Thanks for reaching out and discussing a way forward. I am not on the phabricator team but I do have an interest in its integration capabilities with mercurial. At best I might be able to summarize my understanding of some of phabricator's needs based on the history of this task, but I do not feel I could properly represent them on mercurial's mailing-list or wiki. For hosting repositories I believe this task would require needing to know if the mercurial operation is read or write -- the two primary reasons being read/write access control and cluster picking.

Thanks for the suggestion but we have no current plans to un-prototype Phortune. Fork / patch as you need locally.

Duplicate thing filed in T11800.

I'm going to file the duplicate import thing as a separate task since it probably won't come up for a while and close this out.

While I'm hesitant to throw stones here and don't really have any context on bundle2 or the wire protocol in general and there may be plenty of reasons that it works like it does, my general impression is that the Mercurial wire protocol is significantly under-designed, and is now on at least the 3rd and possibly 4th iteration of hacks to try to address the lack of actual protocol design.

(Google API integration is covered by T2334 -- you can already interact with Google Calendar via ICS files, but that will add support for using the API instead.)

The Gmail/ICS integration seems to actually work OK in practice, here's an event from this install working (modulo some stuff like us not exporting a host/organizer yet):

I would subscribe to the Paste, and spend 20 seconds updating the file if it changes. Like I mentioned before, this task has already been prioritized and we're not going to work on it until other things in the prioritization queue have been completed. I think self-maintaining is a reasonable work-around.

It looks like T10814, specifically T10814#170824, provide some useful info. Thank you for that link!

I would like to submit a translation to upstream. Where do I start?

P1792 is the German example.

If you want to pursue i18n ahead of the upstream, T10814 has some walkthrough I did with another user. It's basically, dump strings into a file, translate, add to src/extensions. https://secure.phabricator.com/w/community_resources/#translations has examples of Chinese and German users have shared here.

Everything you mention is covered by this task.

In T5267#198537, @chad wrote:

The current status is the infrastructure is provided, but the translations are not (you need to either translate it yourself, or check the community wiki page here for community contributed translations). Then install said translations locally.

The current status is the infrastructure is provided, but the translations are not (you need to either translate it yourself, or check the community wiki page here for community contributed translations). Then install said translations locally.

I'd like to get this task un-stuck. I'm unclear on Phabricator's current internationalization capabilities.

This should be fixed in HEAD of master. Thanks for the report!

We can probably just use the merchant name for now. I could maybe imagine some "International Business Machines, Inc" vs "IBM" stuff down the line, but no immediate issue for "Phacility".

Do we need a new field for subjects or is Merchant Name enough? Not sure both are needed.

seems this is due to I didn't add the --lintall option,
the change is one line removal (existing file at the base commit)
thus it's considered as not concerned, but it is concerned actually because I didn't remove the entire function

In T3179#142498, @lfarkas wrote:

Trac wiki import to Phabricator's Phriction.

Based on svemir's anser in https://secure.phabricator.com/Q12 a not to nice not perfect but more then nothing:

https://github.com/lfarkas/phabricator/blob/master/scripts/util/trac_wiki_import.php