related to T3278, probably?

(See T13251 for followup.)

I believe all (?) of these are now fixed in both master and stable.

There are a very small number of noncritical setQueryParam() callsites in arcanist/ (3), instances/ (1), and services/ (3). Of these 7 callsites, 6 are about building Diviner links. I'm going to leave these as-is for now to generally simplify rolling this out, but they should be updated before setQueryParam() is actually removed.

I'm strongly considering allowing phutil_build_http_querystring() to build PHP-flavored query strings out of arrays again.

The error is less opaque in PHP 7.3:

In T8510#200946, @aklapper wrote:

In https://phabricator.wikimedia.org/T76732#2803813 ksmith brings up that "In the search bar in the toolbar at the top of the screen, searching for "Maps" brings up Maps as the third option. Searching for "Discovery" brings up Discovery as the second option."

Thanks!

This seems largely resolved.

See also T13102/PHI442. The MySQL setting optimizer_search_depth=0 may fix the weird explosive complexity here.

Example usage (for simplicity, requires at least one user named "Jake" on your install to function correctly):

After D19089, you can probably emit a projects(people-named-jake()) token or whatever and have it work for some values of "work" and "whatever". Tentatively, it doesn't look like this needs a lot of API changes, so I'm going to move forward with the simple version of the original request.

@avivey, heads up that I'm renaming PhabricatorQuickSearchEngineExtension to PhabricatorDatasourceEngineExtension. I'm leaving an empty subclass in master for now so that nothing breaks, but will delete it sooner or later, so rename QuickSearch to Datasource in your extends ... statements (and, ideally, class names) at some point before then to keep things working smoothly.

Some followup SHOW INDEXES from the case in PHI47 provided output which didn't have any evidence of key cardinality issues, so it seems less likely that this is a cardinality problem.

oh thanks!

I don't think this is resolved, just an unclear report. To access this screen:

Is there a way to exclude users/projects from a query? A user on our install has asked for a way to search for Differential revisions with Project X as a reviewer where the author is not a member of Project X.

This is an issue specific to the repository names containing hyphens. The code is already calling calling the correct sort functions.

I created these repositories:

Yeah, the user is struck through because they are "closed", which is because they are a bot. This isn't the best way to deal with this, but it dates from early 2014 (D8231) when everything was simpler.

Ah I missed that sentence above, this is why the bot user is disabled:

Mailing list and bot users are also considered "closed" because you usually want to hit normal users instead of them.

Another instance of the bug her:

My intended fix here is:

D17656 is legitimately pretty hacky so this is now entangled with T11110, etc.

This is a sort-of-intended result of several different rules colliding to make a mess. Here's the primary rule:

Hmm. Ok. Deleted.

Specifically, this task is about how the javascript in typeaheads rank and match choices.

Not similar.

That sounds reasonable to me. We remain open to more feedback here if it does turn up, but I think we don't have a clear set of next steps otherwise. Thanks for following up!

In T11034#201013, @epriestley wrote:

If there's some remaining use case here, I'd also like to step back and understand it better since I suspect the best solution we can pursue is not any kind of UI change which makes it easier to find things by randomly typing guesses into the typeahead.

I've marked D17192 as resolving this because viewer() now means "viewer, their projects, and their packages", like Differential. exact(<user>) can be used for exactly a specific user.

This one is fine, I'm still going to fiddle with "in" too.

In T8510#200946, @aklapper wrote:

In https://phabricator.wikimedia.org/T76732#2803813 ksmith brings up that

In the search bar in the toolbar at the top of the screen, searching for "Maps" brings up Maps as the third option. Searching for "Discovery" brings up Discovery as the second option.
When editing a task and entering tags, autocomplete does bring up Maps and Discovery as the first items.

but that could be a separate (unprioritized) task I guess.

Yeah, I tend to agree. I don't really see any approaches we can take here that don't make things a little worse for experienced users who already know what they're looking for, and I'm not sure there's too much of a use case left for less-experienced users.

The main concern for me would be typeaheads are for knowing what you're looking for already, and making that faster / easier. Browse interfaces are for discovery.