@epriestley do you have a list of magic phrases somewhere? I think they'd change per typeaheadsource? I have a rough idea in my head.

Yeah, they'll be dynamic. Here's a rough outline -- I may not implement all of these, but they're the sort of things I'm thinking about:

• Anywhere that you're searching for a user, you'll be able to type "Current Viewer" or similar. This will resolve at runtime to whoever is viewing the results. This is useful for Dashboards, so you can build a query dependent that shows assigned tasks for whoever is looking at it, for example.
• When searching for multiple users (for example, "assigned to: ..." in Maniphest) you'll be able to type "Members of project xyz", which will resolve at runtime to the members of that project (as though you had typed all their names in).
• When searching for multiple projects (for example, "in any project: ..." in Maniphest) you'll be able to type "epriestley's projects", which will resolve at runtime to all projects the user is a member of (as though you had typed all of them in). This can let us remove the dedicated and rarely used "In Users' Projects" filter in Maniphest.
• Where "epriestley's projects" is available, you can also use "Current Viewer's Projects".

Slightly more involved cases, which aren't really parameterization:

• It would be nice to merge "Not in projects: ..." into "In Any Project: ..." by letting you select "not in yolo".
• When adding reviewers in Differential, it might be nice to let you select "epriestley" or "epriestley (add as blocking reviewer)".

Overall, the options that are available will depend on what kind of things you're selecting (users, projects, other stuff) and also the context the selection is taking place in (it makes sense to search for "current viewer", but not assign a task to "current viewer").

I think just some kind of sufficiently-different-looking treatment is probably fine here.

I'm going to pretend we like to write javascript when designing this.

Roughed out an initial talking point. Basically:

• I'd like to have a dropdown which will provide hints as to what magic things can be done on this typeahead.
• I'd like to support shorthand/markup in some way for pro users to quickly work.
• Will use a new distinct color/icon only used with magic queries.

It would be interesting in the Typeahead to be able to form complex queries easy like:

Show me all "Phacility" tasks not assigned to me as:

Assigned: #phacility, !chad

Are you considering to interpret #alias in quicksearch box as "in project #alias"? For example, to query a string within the tasks associated to one project only. Right now this is usually a two-step process, first searching for the string, then narrowing to the project.

Original request: https://phabricator.wikimedia.org/T86110

Here's my v0 plan for this:

Instead of a "V" button, I'm going to have a "browse"/"explore" button:

Author: [ Type a username... (•••)]

This pops up a dialog of all results, similar to the "attach" dialog, which:

• allows the user to learn about parameters;
• allows the user to browse results.

It looks something like this:

+---------------------------------------------------+
| Choose a User                                     |
+---------------------------------------------------+
| Filter: (_______________________________________) |
+---------------------------------------------------+
| [!] Current Viewer                      [Select] ^|
| [!] No One                              [Select] =|
| [o] alincoln                            [Select] =|
| [o] bobama                              [Select] =|
| [o] htaft                               [Select] V|
+---------------------------------------------------+
|                                           (Close) |
+---------------------------------------------------+

You can scroll through however many thousands of results there are and filter them by using the filter if you have no idea what you're looking for. This will also teach users about parameterized queries. The UI can be more nuanced and show users that typing viewer() chooses "Current Viewer", and members(differential) chooses "Members of project Differential".

If there are too many typeahead matches, we can add a 6th "more..." item which pops the dialog up with the filter pre-populated to the current query. This will cover the case where installs have 100 projects which all have basically the same name.

In T5750#95455, @qgil wrote:

Are you considering to interpret #alias in quicksearch box as "in project #alias"? For example, to query a string within the tasks associated to one project only. Right now this is usually a two-step process, first searching for the string, then narrowing to the project.

Original request: https://phabricator.wikimedia.org/T86110

It's an interesting idea to me at least. Up to @epriestley, probably worth a separate task.

This is opening up into some very deep infrastructure work.

To present the pageable browse view, we need to be able to iterate a cursor over disparate result types. For example, if a typeahead allows you to select users or projects, results like this are possible:

@alincoln
#apple
@bclinton
@bobama
#banana
...

We need to be able to generate a single scalar cursor for the composite result list, so we can know that the next page of results starts after @bobama in the underlying user query and after #banana in the underlying project query (the cost of not doing this is that every time you click "more results", the next page becomes slower, so the 20th page takes 20x longer to come back).

Generating a scalar cursor is not currently possible because we play it fairly fast-and-loose with ordering and paging in queries. We need to make ordering and paging more formal and robust before we can build a composite cursor-based query. This requires touching quite a lot of code and likely refactoring a fair bit of it.

I cheated them into existence, but unified, browsable lists do work now: