Is T4475 the correct fix then? I do agree these forms are awful, which is why I'd prefer people not end up there.

Regular search doesn't provide good enough results / ranking. Maniphests' neither, but at least you can define more accurate parameters to restrict the amount of results. This is why users really needing to find a specific task end up using Maniphest's advanced search pretty quickly.

Can you provide an example here? The application level search is primarily intended to build search queries that get saved for later re-use. For searching in general, I'd expect the regular advanced search to be used.

We should make middle clicks work as expected though, regardless.

We already have planned several UI improvements to Typeaheads, see T1906 and T6579.

A more specific use case: when I am adding a new task and am unsure whether it fits into a certain project, typing that project name in the search box and middle-clicking would be a convenient way of checking that project's description.

Project names, user names. Admittedly it's not something I would use often, but it did annoy me a few times.

I understand the point, but I personally can't think of what data in the main search typeahead someone would want to do that with. Projects names?

Closed by commit rP4506018339a0.

One way of doing this is by adjusting the mapping for the elasticsearch index (actually way more powerful than a wildcard search).
I currently switched to the mapping below (added as a template expecting the index to be named 'phabricator' and with an english language setting).
Feel free to change the min/max ngrams setting (e.g. 4 instead of 3 letter ngrams) if you get too many / few results.
If you like to switch to another language the docs to do so are here: http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/analysis-lang-analyzer.html
For it to take effect you have to delete the index and then reindex all objects (bin/index --all).

I think the simplest fix is:

Thank you!

T4100 and T5733 cover different ways to approach this feature.

I understood your report.

This is not support request.
Same problem appears at yours: https://secure.phabricator.com/
Take target.phid

Ah, we don't take bug reports or provide support for Prototype applications. See https://secure.phabricator.com/book/phabricator/article/prototypes/ for more information

You have to use target.phid string from Harbormaster

I can't reproduce this on my local install, just this install.

(I would like this tooooo)

Same problem in our instance, and we also have Elasticsearch. See https://phabricator.wikimedia.org/T679

The task description has a little spec that I like over a setup warning. Support Impact part is true given the recent merge action.

This has recently had some Support Impact. A setup warning seems reasonable?

Maybe this pattern could help: this particular wiki document was moved ("This document was moved from elsewhere"). The second error I get on reindexing also refers to a wiki document that was moved.

In T6406#81315, @epriestley wrote:

• Running bin/remove destroy <phid> is usually a reasonable way to resolve the error. Ignoring it is also reasonable.

I've tried that just now:

tools@dev1:~/phabricator/phabricator/bin$ ./remove destroy PHID-WIKI-amenci5bzyxy5k4ndwwu
Usage Exception: No such object "PHID-WIKI-amenci5bzyxy5k4ndwwu" exists!

So I did a text search through all databases and found relations to this PHID in the following tables:

• feed_storydata
• feed_storyreference
• phriction_document
• search_document
• search_documentfield
• search_documentrelationship
• worker_taskdata

Maybe this could help in finding the source of the bug. Thanks for the explanation, I'll just ignore it for now!

In T6406#81303, @btrahan wrote:

Huh, I didn't know that was possible. How does one check the definitive shell history of all users on a given host?

We have single user access for our central phabricator install, whose sessions are explicitly logged in case of stuff like this :)

• This warning seems scary, but is super minor. We should probably tailor the output to make this more clear, or silence the warning entirely when running in batch (--all or --type) modes (showing it when indexing a single object probably still makes sense).
• Usually, this is because some sub-object doesn't exist. In this case, when we load a wiki page we also load the content. Probably the content has gone missing somehow. We decline to load partial objects and fail with this error. Other cases are, e.g., a commit with a missing repository.
• Running bin/remove destroy <phid> is usually a reasonable way to resolve the error. Ignoring it is also reasonable.
• The root cause is probably an actual bug, but we don't have nearly enough information to figure out what happened by just seeing that something went missing (there's no way to reproduce the issue, and in most or all cases examining the database doesn't give us any more information). There are a handful of outstanding issues with Phriction, particularly around moves/renames and project integration, so whatever the root cause was will probably be fixed when we clean that stuff up.

Thanks for the quick turnaround! Much appreciated guys.

Closed by commit rPde40bc0c1d86.

After D10748:

Oh, right, there's no fulltext search support for custom fields right now. Fixing description indexing is simple, let me just do that first and we'll go from there. We could build custom field fulltext stuff too, potentially, but that's far more involved.

I added a custom text field to my projects and made it searchable.

You can also have Herald rules adding i.e. "offline" tag-project to any task associated with "Offline Email Reader" project.

Ah, sure, we can make that text searchable.

Closed by commit rP934eea2ef2a0.

We are starting with phabricator and would really like this feature.

Actually, we can work around this quite nicely after talking with folks. If auto_create_index is set to false, we just need to create an empty index and it'll figure out the mapping when the first document is inserted. In ES speak, it's just issuing a simple PUT to the bare index that doesn't exist yet: curl -s -XPUT <es-host>:9200/<index-name>

Cool, thanks!

No, nothing incorrect about your usage, just need to detect the scenario and error out properly. There's two workarounds:

• Disable the setting completely, create your index, turn the setting back to how you had it
• Configure the setting to whitelist the phabricator* index and blacklist the others.

This is a bit complicated. We return nonzero on a "hard" error, like a bad type:

auto_create_index is on by default, right? Users would have had to turn it off explicitly when configuring ElasticSearch, and we'd compensate for this by checking for the value of the setting and then printing a warning reminding them about the configuration change they made? Or is the way we're inserting documents fundamentally incorrect?

(for a bit of background: we've got this set to false at WMF because ES has a bad habit of not creating indexes exactly as we'd like them so we don't trust it to and have an index-creation script ourselves)

We don't have a typeahead-friendly index for articles right now, but can do this in the future. It probably won't happen before other infrastructure work like T4029.