Occasionally, even after running the re-parse command, the basics of the commit will import but the content itself will not. A phd restart will almost immediately allow the commit to then import.

But other interfaces around Phabricator are not going to fair as well, just FYI.

Server side reduces this quite a bit:

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:

@20after4 : Ah. So by default, everyone just gets a "create task" option, which would never use any custom forms or subtypes. That does seem to resolve my concerns (although I still think it would be cool for phab to behave differently depending on which project(s) I was viewing).

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!

@ksmith: Thanks to the new 'favorites' menu, each user can customize their menu, there is no longer a global 'create new' menu, as it's been replaced.

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?

Our phabricator instance (WMF) is shared by many(!) different projects and teams. If I understand the current proposal, all the subtypes and forms would be available to all users across all teams and projects, except where specific access is limited (e.g. security issues). I think that forces us to either: a) have very few subtypes, which manage to achieve consensus, or b) have a lot of subtypes, which would mean that everyone's "create new" menu would be very cluttered.

I'd love to see anchor indicators when hovering headings.

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 have written a couple of scripts to semi-automatically convert trac ("done") and roundup (WIP) to phabricator. The included patch based on D10754 but extended does quite a good job at faking timestamps even for subtasks and notifications etc, but the whole thing is neither complete nor bullet-proof or even convenient. Good enough for people who don't mind to get their hands dirty: https://github.com/lambdafu/phabricator-test

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

I think that's right, yes.

Users do count, but I thiiiiiink user mentions are a special kind of mention because they have more complicated rules and you can't read them with edge.search today. T4654 discusses better rules around "notify me when I'm mentioned"; there are some related Conpherence-specific tasks too.

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

The table in the description references a getConduitFieldKey method – which I can't find reference to ever existing in the source. Was that supposed to be getFieldKeyForConduit?

In T12314#213245, @epriestley wrote:

Weakness: Subtyping is Probably Only Useful in Maniphest

Subtyping is likely to involve a large number of changes in shared infrastructure (EditEngine), but they will probably only ever be useful in Maniphest. Although most applications now use EditEngine, I can't really come up with any good use cases for subtyping in other applications. Perhaps Calendar could use subtyping on events, but this feels like a solution searching for a problem.

I don't suppose users count as objects in this context? I'd love to have a way to be notified of new @mentions for my username. A client app that queries conduit occasionally and sends me desktop notifications, well, that would just be super cool.

I agree that results should almost always be on the first page and ideally near the top of the first page. I'm also tempted to say that 10 results per page might be closer to the right number than 100.

While the number (>0) of query results would decide whether a given panel is shown or not, also exposing the actual number of results would be IMHO interesting in the context of tabbed panels, so that each tab title could be shown as demonstrated in the mock-up below (please excuse my non-designer-ish CSS skills):

I agree with the general understanding of Adminstrators not being in absolute power.
But then again, it would be useful to be able to have a way to test the effective policies applied to a given user.

In terms of application/code stability, it would be good to handle this properly.

courageous 🎆

True story, I built these because of @jmeador

I dropped the cache, looks like they're working.

I presume these will pop in as cache expires?

rolling.

Specifically, I suspect it won't affect repo because db restarts separately, so the database won't be unavailable when daemons on repo restart.

It looks like this might be an issue with MySQL not being available yet when the daemons start. The deployment script restarts MySQL, then immediately restarts the daemons, and a bunch of this stuff is ending up in the log in the 1-2 seconds after the restart:

I believe that's unavoidable with offset-based paging (the solution is to switch to cursor-based paging, but I think we can't do that for fulltext).

I'll investigate further into the slowness (I wasn't involved in the debugging so far so I don't know more than what's said in the task)

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.

🍞 🐦

fancy 👑