Well, I unhijacked symbol function_name as longhand for s function_name too.

We also hijack the word "symbol" but that seems more reasonable than "help". And we hijack a bunch of single letters, but those aren't normally reasonable search queries.

Yeah, I think this is a hijack and agree with removing it. This came from "Jump Nav" where it made perfect sense, but when jump nav got merged with global search I think this stopped making very much sense.

It's definitely a bit edge case but a user filed a bug against the error for our pre-D11830 instance, which I why I am here bugging you now :)

I would concur on the hi-jack and would vote to remove, though surprisingly I don't think it's come up.

As indicated pre-D11830 when I search 'help' I see:

Will do a bit of leg work on my end to confirm. thank you!

Well, possibly fixed by D11830. But was certainly broken before D11830.

This was probably fixed by D11830. Are you behind rP84d4142b06b71e7dfe86f3c2c5c6b98973d1431c?

Even more confusing than mixed tasks and commits, I find mixed tasks and codereviews, since they will have the same title, and just use a different callsign. The texts "Commit" and "Revision" below the callsign do not help much, since many people use the terms interchangeably.

We aren't going to change the default in the upstream or prioritize document types within it -- it's not some weird mishmash like "commits and tasks", it's "all documents". I think this is the only reasonable default. Some installs do not use Maniphest at all, for example.

It looks like changing the order of items in getBuiltinQueryNames() in src/applications/search/query/PhabricatorSearchApplicationSearchEngine.php works for those accounts that still have the initial default order of searches and does not reset any custom orders set by existing account owners?

In T7266#96398, @qgil wrote:

I think that what actually confuses users is that the default option for general search after they register is not "Open tasks". Whenever they use the search field in the header, they get all those commits mixed with tasks, and they wonder why.

"tabular results" get suggested maybe 1-2 times a year, so there isn't much interest on our side to pursue that at the moment, there just are larger gains to be made in other areas of ApplicationSearch and we are interested in working on that with the types of example you explained. Thanks for putting that together.

T6943#96234 and T4100 are mostly like already on this course. Going to close this in favor of those for discussion.

@epriestley @chad Sorry about the references to things that may not be meaningful. I'll try to expand.

I think you're coming from an environment which is very different from this one, and have a lot of expectations about how projects work that aren't true for this project. In particular, although this project is open source, it is not run by the community. You can find more information here:

I'm not reporting a documentation issue here. I'm asking for the possibility to do an AND search even if an installation is set up to do OR by default (which is even mentioned as a possibility in the screenshots above). I was told MySQL supports +. So the only thing you need to implement is a replacement of AND with +. That's not "an entire fulltext engine". Why do you say that?

We strongly need features requests to solve real problems, we don't spend time on features or tasks that only exist in a theoretical space.

Phabricator uses MYSQL's fulltext search features, if MYSQL is not configured in a way that supports AND searches, then what can Phabricator do (besides write an entire MYSQL fulltext engine in PHP)?

there is nothing that can be done.

Look, what epriestley is saying is that as long as Phabricator is configured according to its setup instructions it uses AND by default.

Administrators receive explicit, detailed instructions.

No hint of how to solve the actual problem other than "according to the instructions". Basically a RTFM. Not helpful.

When properly configured, all searches are AND searches, and "and" is a stopword so "x AND y" will have the same effect as "x y" and search for both terms. Phabricator raises setup warnings to help you configure it properly. If your install is not configured properly, you should pursue this with your administrators.

I'm sorry?

• No hint of how to solve the actual problem other than "according to the instructions". Basically a RTFM. Not helpful.
• Ignoring the fact that I'm describing an actual problem and calling it "hypothetical". What the heck?
• Ignoring the fact that I'm not asking for an OR operator but for an AND operator.

Probably the first and last time I'm reporting something here.

When configured according to the setup instructions, AND is the default. It looks like your install's administrators are planning to update the configuration.

What I actually wanted to use is AND.

Can you give me an example of an "OR" query you'd like to run? What problem do you hope to solve by using OR queries?

I have no idea what "Project Studio" is and Google doesn't seem helpful either.

We have a similar request in Wikimedia that could be solved in the same way: Allow sorting by oldest and newest in Date Update/Created in search queries

I think that what actually confuses users is that the default option for general search after they register is not "Open tasks". Whenever they use the search field in the header, they get all those commits mixed with tasks, and they wonder why.

Given a bit of thought to this, and a lot of research into competing products. In essence I think T4100 is the correct path, but with a slightly more expanded role - basically go all in.

T7251 is a suggestion of a UI I particularly like - the Product Studio (Microsoft's internal bug tracker) / "query builder" interface.

Can you list some queries you'd like to execute that you can not currently execute, and why those queries are interesting/useful (e.g., what problem does seeing that result set solve)?

(also, if you have examples from other sites you feel do this well, feel free to drop inspiration here).

Sure.

Is this yoinkable for a Design direction? I can easily bang out a few mocks this week of various ideas. Short-term, I think we're wasting a lot of space. Long term, I want to make sure the experience is simple for new users, and powerful for people who have to sit in it all day.

I don't have a quick and easy answer for this, except to say this doesn't feel like a long term solution. It could be maybe if it was very very basic (1-2 fields already open, maybe Projects and Text) and everything else is advanced. Basically, if we could get 90% of searches with 2 fields, then maybe, I'm not sure though we have that information.

I think T6943 is the short term fix, and not every person will be happy with it.

Oh, and to clarify, my crazy-complicated proposal is the same as this, except we would additionally have an "edit" option which let users drag fields from "Basic" to "Advanced" or vice versa, and reorder fields within either view. Hiding fields (dragging them to "advanced") wouldn't remove them completely, it would just put them behind a "click to see all fields" disclosure.

At least as a user, I would partition "Contains Words" into the "Advanced" mode, which would make this task worse.

• I think this worth trying, but I'm worried it won't be flexible enough to stick as a permanent solution. Specifically, my guess is that any partition we create of "basic" vs "advanced" fields will find lots of disagreement among users, and be something new for them to file feature requests about.
  • This might not even be that easy, since, e.g., if you're viewing a query result which uses any of the "advanced" fields, we should expand them by default (i.e., never hide active filters). So it might require making the search engine significantly more aware of fields as first-class objects anyway. But maybe we could just cheat / hard-code that.

It looks like this task could be merged with T6943: Create "basic" and "advanced" modes in Maniphest Search UI?

I generally disfavor this approach since I think it will lead to even more bikeshedding ("X option is important, please move it to the default list!"), but it's way easier to try than the mess I proposed in D11306#106055.

@chad / @epriestley - feel free to say this is an outright bad idea, etc. Otherwise though I want to get moving on it.

Thanks @fabe.
I resolved that issue after search init and change mysql config ( STRICT option ).
It works well but I found T6892.

just run

./bin/search init

first.
This will create the needed elasticsearch index.

Thank you for your answer. But I met this error message.
after "search index --all"

[HTTP/404] Not Found
{"error":"IndexMissingException[[phabricator] missing]","status":404}

Is it need more configuration for this?

https://secure.phabricator.com/T5282#62676

Is there a temporary way to resolve this issue? ( Just only for wiki search )

See also T5352: Add ability to filter tasks on blocking status in search queries

I have fiddled a bit with this, and I've got a few implementation questions.

Presuming resolved by D11030.

Presuming resolved by D10955, yell if I missed something or there's some followup.

Closed by commit rPc953c0fedc17.

The stemmer should probably make an effort to preserve exact phrase search. Likely, this means special handling of quoted terms when tokenizing and stemming the query.

Yeah, this is specific to ElasticSearch -- exact phrase search works on this install with the MySQL backend T6747.

Thanks! The + thing didn't work but I've just asked the team that owns the Phabricator install to change the config setting.

If you're using the MySQL index (I think you are), the MySQL configuration value ft_boolean_syntax should be set per the edited task description. We'll add a setup warning to make this more clear to administrators.

Huh, our install definitely treats it as an OR. Do you know which configuration settings I should be looking at to control it?

I think search already works like this? It depends on some configuration settings, but, for example, if you search for "search" on this install, you get 100+ results:

I this.

We had that, almost exactly:

In T6717#87036, @epriestley wrote:

In general, I'd strongly prefer to improve search based on specific problems with finding information, rather than, e.g., intuition about which fields are probably popular.

In https://phabricator.wikimedia.org/T76273#839187, @tgr wrote:

at the very least, the filter should be set when I am in one of the subareas of Phabricator. I.e. when I am in Maniphest (looking at a bug), the search should be limited to bugs; when I am in Diffusion, the search should be limited to commits.

Compare how e.g. Github works: when you are in a repo, the search box has a little "This repository" tag in it (which can be cleared by backspace) which limits the search to the current repo. Something similar could be done in Phabricator with the applications: when you are e.g. in Maniphest, show a little "Tasks" prefix which can be removed, and if it is not removed, the quicksearch should send you to the Maniphest search form (which has different controls, so filtering is not the only reason why it is far superior to the general search form) instead of the generic search form.

Sure, send me a diff?

That number sound high to me, at least higher than I'd expect for something being under the page fold. It seems reasonable to move it up at least, maybe above status?

The downstream task makes this claim: