We can look at the server side issue, but we already have text-overflow on this element, so it's not going to resolve the core problem.

I agree that long project names might a problem on its own - but for now this was a compromise I had to make to compensate for the fact that projects are just "generic" containers which can't be further classified to distinguish between ACL groups/projects/tags.

This is working as intended. If you choose significantly long project names, many pieces of Phabricator will naturally become less useful and more difficult for you users to use.

More info: the commit contained binary files (executables actually).

We now have one that's failing even when forcing a reparse:

Is there a way to recall the logs from a failing task? Is there any value in providing the logs for the successful task? Not really sure what to say here besides that it's a consistent and random issue on our repositories. When we run the trace, it then "bumps" the task somehow and things succeed, so it would be difficult to provide detail on an error.

There isn't enough information here for us to reproduce this, or even begin.

In T12363#214538, @chad wrote:

What are you attempting to do here or was this accidental?

What are you attempting to do here or was this accidental?

I wouldn't expect anything in the logs; You can try running a script and running something like this:

$d = new DateTimeZone("Asia/Jerusalem");
var_dump($d->getOffset(new DateTime('@'.time())));

IF you're getting back FALSE, then it's definitely this.

Hooray!

This was fixed in rPb28da10336ca 😄

Beautiful and timely fix. Thanks!

@avivey Thanks! my php version is PHP 5.5.9, would you recommend upgrading? I didn't find anything in my php error log though, any suggestion where else I could look into to find out the cause?

You guys fast.

I fixed that hours ago.

Hi! I think I've hit similar issue, but for another type of panel. We've used to use PhrequentSearchEngine panel to show phrequent/query/tracking/ (Currently tracking), which apparently got removed in D17341. Currently tracking on main dashboard was quite interesting indicator for current work aaand could be fun until phrequent gets more useul 😄

You can adjust the validation here:

I went with a different color, but we could also do text-shadow or a background-color... lmk if this seems bad in practice.

Sometimes, Apache is configured with a rule which prevents any access to any URL which contains /..

In T12357#214422, @chad wrote:

What would you suggest as a fix?

What would you suggest as a fix?

This is not a bug. If you feel this is a security issue, please file an appropriate task on HackerOne. https://hackerone.com/phabricator

I would argue that at least for email ("External Targets"), we should always include the timezone when rendering times. When we allowed custom time-format, I've also added it there (Partly because there wasn't the time-zone warning we have now, partly because I kept my phabricator config to PST when traveling, and partly to make copying the time easier).

In T12349#214295, @epriestley wrote:

Hrrm, it looks like my reply to your email bounced. Short answer is that we don't offer anything special for academic or open source right now. We'd like to in the future, but are focusing on building our core business first.

In T12349#214207, @epriestley wrote:

The document contains "bash". This behavior seems correct to me.

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

Hrrm, it looks like my reply to your email bounced. Short answer is that we don't offer anything special for academic or open source right now. We'd like to in the future, but are focusing on building our core business first.

The document contains "bash". This behavior seems correct to me.

This is the search that shows the problem: https://secure.phabricator.com/search/query/lOkcMy6H_Jmk/#R

Thanks a lot for this ultra-fast reaction & fix.

This should be resolved at HEAD of master, thanks for the report!

I was able to reproduce it, sorry for mis-reading.

In T12347#214146, @eliaspro wrote:

Is it possible that symlinks could cause this issue?
libphutil and arcanist are symlinked from their current builds to the location where Phabricator expects to find them.

I assume this is broken for any EditEngine not tasks

Whoops, no my mistake. I tested Task forms, not Projects.

Although our deployment mechanisms should take care of this on their own, I specifically made sure everything is restarted etc. for reproducing this issue and producing the error logs.

I can't reproduce this. Did you recently update and forget to restart the webserver/PHP?

I don't think I can close this. Can you please do it?

@chad You're right, should've gone to Conpherence first.

File a new bug report if you're still having issues at HEAD

Anyone knows a any dirty (or not) fix for this, like a ninja mysql management move?

We'll still need reproduction steps to accept this as a bug report. If you just have questions about what to do next or if it's a bug at all, Conpherence and Ponder are community support. See Contributing Bug Reports and Providing Reproduction Steps for more information.

Workaround is to URL-encode the parenthesis (%29) or use the remarkup style

[Back to the Future](https://en.wikipedia.org/wiki/Starship_Troopers_(film%29)
[[ https://en.wikipedia.org/wiki/Starship_Troopers_(film) | Jurassic Park ]]

Results in:
[Back to the Future](https://en.wikipedia.org/wiki/Starship_Troopers_(film%29)
Jurassic Park

D17452 marks this as resolved and makes these changes:

I like the idea of a feed/panel that shows recently active objects and not the individual events, but I don't know that I have a specific use case for it now. For how I use feed I think being able to filter out commits would be a nifty plus, as those tend to pollute the feed during arc land activity (and comments in tow). I don't think I feel too strongly about it right now though, as most of my work is driven via email activity and I primarily use Feed as a means of discoverability so I can poke my head in if something sounds interesting~

Thanks for the information @epriestley.

You can set history.immutable to true in your repository to prevent arc from performing mutation operations (amends, squash-merges).

Not a bug.

I don't think there's any way to check for that via Herald. There's the Land Revision button( T182), which I ❤, but it's still a prototype and has some surprising behavior built into it (If you're doing anything complex, it can sometime land stuff you didn't want it to).

arc land mutates the code (adds details, squashes), so it's not possible. I'd recommend restricting who can land code and have the accepted reviewers manually land with "Land Revision" from the web ui. In general we expect people to trust co-workers, or use Audit for post-commit coverage.

(Going to close since this isn't a bug report. My mistake on reading the reproduction steps, @avivey has better eyes than I)