This is not working for me, as described as part of T99739. I don't feel bold enough to reopen it myself, but believe that it should be reopened.

I'd also expect exact match of secondary hashtags to win.

Still an issue. Example: Enter discovery (the primary name of a project) in the Projects field on https://phabricator.wikimedia.org/maniphest/query/advanced/ , the five proposals do not include the "Discovery" project itself.

I've created https://secure.phabricator.com/T8510

Things got worse with the subprojects:

I use a greasemonkey script to get around this problem. This overrides the suggestion-limiter to 100.
It's documented onwiki at https://www.mediawiki.org/wiki/Team_Practices_Group/Phabricator_tips/Maniphest#Autocomplete_limit
and quick install at https://openuserjs.org/scripts/quiddity-wp/wikimedia_phabricator_suggestion_expander

However, it's only partially successful in some instances, such as the new "Actions" dropdown menus, and I haven't had time to investigate/fix it. (I assume z-index... but that's all a little outside my familiarity.)

There is still one upstream task[1] that remains open, unlike most of the related tasks about this issue which have been closed as either resolved or invlaid, without totally resolving the underlying problems.

[1]: https://secure.phabricator.com/T7858

@mmodell : It is not clear to me that the upstream task would actually fix this issue. I think we should either get this case explicitly called out in that task, or we should file a new upstream task.

As a specific reproducible example, in case anyone needs one: Entering Discovery in the Tags field still does not offer Discovery-ARCHIVED, which has been frustrating us for over a year.

@ksmith: I totally agree that this is a problem and also that the upstream task may not be exactly applicable. I only linked it because it seemed somewhat relevant.

Allegedly fixed upstream: https://secure.phabricator.com/T8510#177463

@Qgil: Thanks for pointing to that. It looks like they're going to sort the projects by displayed name, which should at least fix the Discovery case.

I still think their fix is "wrong", in the sense that I believe that an exact match should always win, no matter what order the results appear in. But it should be "good enough", at least for the cases I'm aware of.

In T76732#1334152, @Nemo_bis wrote:

I'd also expect exact match of secondary hashtags to win.

Was this supposed to happen, after T135068? It didn't.

https://secure.phabricator.com/T8510 is not fully fixed yet, and this can still be reproduced trying to add "Wikidata" for example.

More fixes coming this week, hopefully this one is fully fixed after the update.

Nothing seems to be changed, it's still not possible to add the project Wikidata to tasks.

In T76732#2382047, @Sjoerddebruin wrote:

… it's not possible to add the project Wikidata to tasks.

Click the search button then select it.

(This is a test, clicking the search button, typing "Wikidata", and selecting it from the long list.)

For the records, https://secure.phabricator.com/T6102 is fixed upstream; https://secure.phabricator.com/T8510 not yet.

Status of three testcases, after latest deployment on 2016-06-15:

Discovery (which has numerous additional hashtags):

• ✔ Using "Change Project Tags" under "Actions" above the field to add a Comment and entering "Discovery", the 2nd item among the 5 proposals is "Discovery".
• ✔ Using the global search in the upper right corner, "Discovery" is the 2nd item among the 10 proposals.
• ✔ Using the "Tags" field on https://phabricator.wikimedia.org/maniphest/query/advanced/ and entering "Discovery", it is the 2nd item among the 5 proposals.

Labs (which has no additional hashtags):

• ✔ Using "Change Project Tags" under "Actions" above the field to add a Comment and entering "Labs", it is the 1st item among the 5 proposals.
• ✔ Using the global search in the upper right corner, "Labs" is the 7th item among the 10 proposals.
• ✔ Using the "Tags" field on https://phabricator.wikimedia.org/maniphest/query/advanced/ and entering "Labs", it is the 1st item among the 5 proposals.

Wikidata (which has no additional hashtags):

• ✔ Using "Change Project Tags" under "Actions" above the field to add a Comment and entering "Wikidata", it is the 1st item among the 5 proposals.
• ✔ Using the global search in the upper right corner, "Wikidata" is the 10th item among the 10 proposals.
• ✗ Using the "Tags" field on https://phabricator.wikimedia.org/maniphest/query/advanced/ and entering "Wikidata", it is NOT among the 5 proposals:

I think the last one might be because there are a ton of additional hashtags on some of the wikidata related projects, causing them to win out in the relevance scoring.

For example:

MediaWiki-extensions-WikibaseClient has the following 'additional hashtags':

#MediaWiki-extensions-WikidataClient, #mediawiki-extensions-wikidataclient, #MediaWiki-extensions-Wikibase-Client, #MediaWiki-extensions-Wikibase+Client, #mediawiki-extensions-wikibase+client

Removing Phabricator (2016-06-29) project since https://secure.phabricator.com/T8510 is still open and no time frame for that to be fixed.

I see some issues, but is the original complain still valid?

At least for "Wikidata" the situation is still bad unfortunately.

@Lydia_Pintscher to me it looks like it's fixed now. At least for the cases I've tried, Wikidata was always at the top or at least in the list.

I think I see the issue- by searching wikidata on the general form, Wikidata is not on top. I think that is a different issues than entering "wikidata" in a project-specific form (like creating a new ticket)- and not necessarily something we want (needs discussion). I would suggest to close this one as resolved and not increase the scope of it. If I write #wikidata or #wikidata-query on this very same same test form, I get exact results as expected while I am writing.

Then create a new subtask, if needed, of T146843 as that is related to improve general search results, and not to auto-complete (which seems mostly fine).

The original request was "exact matches should always win", which I interpret as saying they should always be the top match. And I agree. I'm frustrated that for some reason it seems like that change isn't going to be made.

If this task is closed (which I wouldn't object to at this point), I really think it should be "declined", not "resolved". It's really not resolved/fixed. But at least in most cases the exact match seems to be shown in the list. Even if it's at the bottom rather than the top.

https://secure.phabricator.com/T8510#199629 states this should be pretty much resolved.
We're now running that version here, with an additional backported patch on top. And so far it looks like a great improvement!

Testing in the Tags field on https://phabricator.wikimedia.org/maniphest/query/advanced/ , some stuff surprised me:

• Entering Labs not displays Not In: Labs as 4th item.
• Entering labs not in only displays Not In: Labs-Infrastructure but not Not In: Labs
• Entering Wikidata now shows the Wikidata project as the first result. \o/
• I have not been successful yet in getting Not in: Wikidata offered somehow. Entering wikidata in I only get three options related to the MediaWiki-extensions-WikibaseMediaInfo project.

If anyone has examples of exact matches not getting offered first, please add them to this task.

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.

This task was originally filed for the editing case, so although I personally think both cases should be fixed, it seems the remaining issues should be captured in a separate task.

I have tested with VisualEditor, which wouldn't show up before due to all the related subprojects. Now it appears in the first position. Good!