related to T3278, probably?
Jul 25 2020
Jun 24 2020
Jul 14 2019
Feb 16 2019
(See T13251 for followup.)
I believe all (?) of these are now fixed in both master and stable.
Feb 15 2019
Feb 13 2019
Feb 12 2019
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.
Feb 11 2019
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:
Dec 18 2018
Jun 29 2018
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."
Jun 1 2018
Apr 8 2018
Apr 7 2018
Apr 4 2018
This seems largely resolved.
Mar 19 2018
Feb 15 2018
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.
Feb 14 2018
@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.
Sep 20 2017
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.
Aug 21 2017
Aug 6 2017
I don't think this is resolved, just an unclear report. To access this screen:
Jul 7 2017
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.
Jul 3 2017
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:
May 25 2017
May 9 2017
Apr 24 2017
Apr 17 2017
Apr 14 2017
Apr 12 2017
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.
My intended fix here is:
Apr 11 2017
This is a sort-of-intended result of several different rules colliding to make a mess. Here's the primary rule:
Mar 28 2017
Mar 22 2017
Hmm. Ok. Deleted.
Mar 16 2017
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!
Mar 15 2017
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.
Jan 12 2017
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.
Jan 10 2017
Nov 29 2016
This one is fine, I'm still going to fiddle with "in" too.
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.
Nov 18 2016
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.