Yeah, I think it's very unlikely that we'll require hovering to reveal document hierarchy (or, eventually, parent projects) since two results called "Onboarding" (or, in the future, "Sprint 32") are completely indistinguishable right now. This use case feels much stronger to me as a material usability issue than snippeting.

Thanks for adding me to this issue! Please don't rely on mouseovers/hovering. I want to be able to just look at the results and see which ones are relevant without having to move my mouse.

I think we'd likely want to pursue T8646 first and see if that resolves this on its own.

Can you suggest the best way to achieve this?

I remember we had this implemented before, but can not find task why it was removed.

D14097 reverts this because it felt really bad in production, and generally not very promising as a direction we could iterate on and make successful.

pls revert. pls.

How about we:

I mocked this out and intended to build it into the redesign for PHUIObjectItemListView, but never got to it. A snippet/summary button like GitHub uses. Could be useful here.

I searched for 'self actions' earlier today and that search would be much harder now.

Here's a case where the result feels OK, especially if I'm a new user:

On real data, this feels very bloated to me for tasks, at least:

This doesn't feel completely solid to us yet so we're going to try it out for a bit and see if there are further adjustments to make. We're interested in feedback on this version of the feature if anyone has a particularly positive or negative experience with it. I'll push it to this install shortly so it's available to play around with.

See that diff for some details, here's what it looks like currently:

D14095 is a rough pass at this. I'm summarizing (showing the first ~paragraph of content) rather than showing contextual content around body search results. This is easier and maybe-better, given that our search results are more highly structured than webpages? I'm not sure if this holds up in practice.

This is technically straightforward but probably needs some design work. I'd guess it's on the order of 2-4 hours depending how messy application/customfield stuff ends up, although that may happen in a technical block and a separate design block. This can be slipped in if approved.

This is easy to change but I'm not really convinced it's better, even though it is inconsistent.

I applied the following change locally. I'm not convinced that it is the most correct solution, but it seems to have worked for our install:

I don't quite understand the use case here... I imagine that importing repositories is something that happens very infrequently and so I think that such a change would have no effect most of the time. Am I misunderstanding?

Comparing the mappings before and after (with curl 'http://localhost:9200/phabricator/_mappings?pretty=true'):

I've made some small progress here.

Pretty sure this was fixed by D13519.

You can build a Dashboard Panel and embed multiple queries. There isn't current OR functionality.

I want to have a query that list all the diff related to me, including author:me, review:me, subscribe:me. Currently the board doesn't support this query. I can only do author:me AND review:me AND subscribe:me.

Currently, these results are essentially never useful to anyone, so I don't think the proposed solution (adding difficult-to-discovery complexity to the typeahead) is very good. Instead, we should improve the quality of the search results. For example, only indexing top-level atoms (in PHP, classes and functions). I believe we already have the concept of "top-level" in Diviner.

Yep, I believe so.

This is probably fixed by rPd5e4d960.

That stack trace is bonkers, I think we're calling tput cols every time we update a progress bar.

I ran this same command on a separate host and stopped the phd daemons before running the command. Doing so allowed the command to complete successfully.

To tie in some context:

Looks like --background is six times faster though: https://secure.phabricator.com/xhprof/profile/PHID-FILE-zy56ub2hhqqmrsgelvdl/

Here's a profile: https://secure.phabricator.com/xhprof/profile/PHID-FILE-6qploks2cyzbwune3vki/

Sorta... My issue isn't that indexing ElasticSearch is slow, rather my issue is that queueing tasks into the daemons seems to be slow (this shouldn't be touching ElasticSearch, also I believe this issue existed when we were using MySQL indexes as well).

Is this different you think than T8306

It might be worth noting that I am running the ./bin/search index command on the same machine that is running our daemons.

Presuming this is resolved by D12967.

Attached diff would be a quick fix. Probably not the right place to put it though. There seems to be no good place to actually call the new setURI/setIndex

• Press / to focus the search input.
• Configure this setting in Settings → Search Preferences.
• Press ? for a list of keyboard commands.

Yeah, this is a bug with the interaction between offsets and limits in the underlying fulltext search query (which finds documents matching the search terms) and policy-aware, cursor-based paging in the application-level query (which filters out documents you can't see). I wasn't able to find a clean fix in 5 minutes of poking at it.

Didn't look at the code yet but it seems like the offset is somehow counted double (try playing with the offset parameter). Decreasing/Increasing it by one will add/remove two results each.
To get the remaining 14 tasks you can do a offset=50 (which will skip the first 100 tasks).

seems to be related to {rP16a8ed72bddaf459a02ee7cd95f232ad0045c05c}