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 👑

I think bin/cache purge --purge-user will do it (but for every user). There's no way to do it for just one user, I don't think.

is there a simple way to reset the cache?

I've implemented a new edge.search API method. This method generally works similarly to other *.search API methods:

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

Here's the intended behavior from the source:

Got it thanks. And would a build be triggered by plan changes flag through the web form? Or only with another arc diff call?

The build system should be able to call Phabricator via Conduit and ask for revision status today if you want a short-term fix.

I understand why this may fall under T2543 but this other task appears to be of much bigger scope and take a very long time to be done, while this seems like a minor enhancement. Plan changes is just an attribute of the revision like summary, reviewers, etc... which you can use as conditions in herald, so why not just add it to herald.

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.

(That is, the expected failure mode of this query when it fails to scale is "silently return an incomplete result set", not "be really slow".)

To start with here, let's identify exactly what's slow? It's not clear to me from the downstream task unless I'm just misreading, and not evident to me from reasoning about the behavior of this query. This query strategy is fundamentally not scalable, but I would not expect it to be slow unless the ElasticSearch query is slow.