by default, all search terms should be AND'ed instead of OR'ed

I can't reproduce this. Here's an example of a search on this install which uses three common terms and finds only one result (this task):

By default, MySQL uses "OR", but we raise a setup check to recommend you adjust this. You may have:

• ignored this setup check; or
• explicitly declined to change the behavior; or
• be running an older version of Phabricator which does not have this check.

This check was added in D11030 (Dec 2014).

exact match within body of task via quotes

I can't reproduce this. Here's an example of a search on this install which finds an exact match in the body using quotes:

Note that without quotes there are many more results:

gmail-style searches, e.g. "to:<name>" to find all tasks assigned to a given person, or "from:<name>" for tasks someone assigns. "subject:<text>" to find a particular subject, etc.

Author and assignee are already supported in Maniphest:

They are also supported in global search:

Search from within Maniphest has more options than global search because not all queries make sense to apply to objects in general, but both these specific options are available in both search interfaces.

I'm not sure how we could make these features more discoveralbe. Do you have suggestions?

T6721 discusses title-only seach.

@epriestley thanks for the detailed reply! I am now working with our DevOps person to change our configurations based on what you advise. Once we tackle all of this based on what you've mentioned, I'll update this task with examples (either suggested changes based on our UX or ways to improve discoverability for functionality that already exists but that we did not discover). Will be in touch in the coming days...

either suggested changes based on our UX or ways to improve discoverability for functionality that already exists but that we did not discover

Maybe also see T10208 for our plan around "Design/UX" feedback. In general we prefer to limit this to Roadmap items only.

Hi @epriestley ;

We are using RDS for our Phabricator database and it is not possible to change the "ft_boolean_syntax" variable.

Since I'm sure many people use RDS, do you think it is possible to find an alternative to the AND vs OR issue?

Thanks

You can use the default syntax (+x +y) to perform an AND search explicitly. See:

http://dev.mysql.com/doc/refman/5.7/en/fulltext-boolean.html

@epriestley @chad I just synced w/my team after doing a bit more research. There are a few items here - apologies ahead of time as I know each item below probably should be its own task, but feel free to separate as you deem fit.

The high level summary of this feedback is that I'm inclined to believe that it's much more intuitive (and thus common) from a user experience standpoint to type into the top-right search box to search maniphest, and almost everyone on our team, especially non-Phab-experts, do this instead of clicking the "Edit Query" box in Maniphest and edit a bunch of fields there as the way people intuitively search. So I think there are many ways to improve the search experience as it relates to Maniphest (and other Phab apps) when using this box.

Suggestions:

1. re: Gmail-style "to:<name>", etc. this is a feature request for a convenience function for power users that Gmail has (e.g. put in your Gmail search the following text: in:inbox is:unread -is:starred "test body text in exact order"). Most of us, especially QA, use Phab daily all day, so we are power users and this would significantly speed up our day (5-10 seconds instead of 1 minute or more per search), especially for QA who does tons of searches all day. In other words, being able to type in the top right search bar, for example, these literal words:

in:maniphest from:davidm to:nicolast status:open created:yesterday priority:high body:"this is text from the body word for word"
instead of doing a lot of clicking around. This efficiency is in Gmail and is a huge time saver

2. The "Search Current Application" option for global search, while better than "Search all documents", has some potential user experience opportunities for improvement:

(2a) when doing a search in Maniphest via the top-right search, the query options are a much less powerful list of features vs Maniphest querying:

(2b) right now when doing a search, we see a ton of closed items (since the default is to show closed and open docs) which makes this UI inefficent to navigate and annoying to always have to check "Open" after realizing this (some folks don't even discover they can do this). It seems like searching open docs only is a much more common use case (you could verify via some surveying or talking with other folks, but I can't think of many use cases for normal users that care about closed docs more than a small % of the time), so I would recommend considering defaulting to open documents for convenience.

(2c) On my phabricator homepage, "Search Current Application" functions the same as "Search All Documents" - most of the time when I want to do anything in Maniphest, I load Phabricator and do a search but it always takes me to this "very simplified experience" without task priority, ownership, or project info instead of the Maniphest search experience. I think the best way to remedy this negative experience would be to have the list UI in "Search all documents" show the same detail of content for Maniphest items as a Maniphest search does. The rest of the items, e.g. wiki pages, can be as they are today in there as necessary. But we'd love the level of detail in Maniphest search that's available in global search (e.g. priority colors, etc.), because right now using Global search for Maniphest feels...not useless, per se, but an inconvenient/annoying experience which has caused a general consensus in our organization of "phabricator search is broken" - in reality I know it's not broken, it's just some of these user experience details make it feel clunky/annoying for us.

3. I understand the +x / +y syntax as an alternative to not being able to edit ft_boolean_syntax, and we will tell everyone on our team and hope they remember. That said, I'm sure you would agree that this is not discoverable. As you can imagine Amazon RDS is very popular (possibly the most popular hosted database service), so it would be amazing if you had a solution that worked on RDS that didn't require us to try to educate our company to use "+" in every word in a query. I don't know if a reasonable solution here is feasible, but that's what I'd recommend considering exploring.

apologies ahead of time as I know each item below probably should be its own task, but feel free to separate as you deem fit.

Yeah, tasks like these are very hard to manage. Just open an individual feature request for each problem you're having using Phabricator. See Contributing Feature Requests for more information.

(2b) right now when doing a search, we see a ton of closed items (since the default is to show closed and open docs) which makes this UI inefficent to navigate and annoying to always have to check "Open" after realizing this (some folks don't even discover they can do this). It seems like searching open docs only is a much more common use case (you could verify via some surveying or talking with other folks, but I can't think of many use cases for normal users that care about closed docs more than a small % of the time), so I would recommend considering defaulting to open documents for convenience.

This is my default query:

Search is an application like Maniphest, you can build, save, and make default whatever queries you use most. Everyone wants something different, so customize it how you like. Otherwise , you'll need to wait for T4103.

See also T8660 for another discussion about searching open and closed documents.

@chad understood - I reviewed https://secure.phabricator.com/book/phabcontrib/article/feature_requests/ - was very informative, thanks! I also commented on T8660.

I filed T10639, T10640, T10641, and T10642 to split this task into separate ones.

One final note, re: 2(b) which is the only item for which I did not file a new task, as you know, most people leave most defaults the same (when I was on the Gmail team it was 80-95% of people depending on the item). I'm hopeful that items like this could have defaults that are more common for the most common phabricator use case. I'm not an expert on what that most common use case is, but my gut is that is would be mostly Maniphest for software development, hence the suggestion.

Just something for you guys to noodle on. :)