Exact matches should always win when suggesting/auto-completing
Open, LowPublic

Tokens
"Pterodactyl" token, awarded by Liuxinyu970226."Pterodactyl" token, awarded by Nnemo."Manufacturing Defect?" token, awarded by Florian."The World Burns" token, awarded by JanZerebecki."Pterodactyl" token, awarded by Addshore.
Assigned To
None
Authored By
daniel, Dec 4 2014

Description

Upstream reports: https://secure.phabricator.com/T6102 and https://secure.phabricator.com/T8510

Workaround by valhallasw:
Execute JX.TypeaheadSource.prototype.setMaximumResultCount(100) in the javascript console (or a userscript)
to get more results displayed. Userscripts at P2444 (Chrome) and P2445 (Firefox)

When typing in the "projects" field in the "edit task" or "edit search" view, phabricator offers up to 5 suggestions/completions. But sometimes, the exact match for what I just typed is not included in this list. This makes it impossible for me to enter these projects anywhere (for me, this happens for "wikidata" - I see "wikidata.org" etc, but not "wikidata"). Interestingly, these suggestions look different for other users (with the same input, they do get "wikidata", though it's only in the 4th slot), so it seems the ranking in the suggester is user-specific (projects that I am a member of get boosted, or some such).

In any case: exact matches should always win. If I enter a full name and hit enter, this should always work if a project by this name exists.

I'm setting this to "high" since it makes it pretty much impossible for me to work with phab.

PS: I suppose the same issue exists for all fields that use the suggester/tag logic, but I did not run into any problems with other fields yet.

Related Objects

There are a very large number of changes, so older changes are hidden. Show Older Changes
Qgil claimed this task.Feb 18 2015, 4:32 PM

This is not fixed for me by https://secure.phabricator.com/rP49ee09be3f453386c91820e990d6916887206eb6
At least not in a way that I would have expected:


Can someone confirm?

ksmith added a subscriber: ksmith.May 20 2015, 3:47 PM

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.

JanZerebecki reopened this task as Open.May 20 2015, 9:25 PM

Yes, can confirm.

demon removed a subscriber: demon.May 21 2015, 11:11 PM

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

Aklapper updated the task description. (Show Details)Jun 11 2015, 11:48 AM

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

Florian added a subscriber: Florian.

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.)

Restricted Application added a subscriber: TerraCodes. · View Herald TranscriptMay 20 2016, 9:30 PM
Quiddity updated the task description. (Show Details)May 20 2016, 9:32 PM

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, 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.

@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.

Krinkle removed a subscriber: Krinkle.Jun 2 2016, 8:43 PM

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.

Sjoerddebruin added a comment.EditedJun 15 2016, 8:45 AM

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

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

Click the search button then select it.

Nikki added a subscriber: Nikki.Jun 15 2016, 8:54 AM

(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

Paladox added a subscriber: Paladox.

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

Restricted Application added a subscriber: Luke081515. · View Herald TranscriptJul 22 2016, 1:09 PM

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).

ksmith added a comment.EditedOct 27 2016, 10:04 PM

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.

Nnemo awarded a token.Nov 8 2016, 8:32 AM
Nnemo added a subscriber: Nnemo.

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.

Qgil added a comment.Nov 18 2016, 11:15 AM

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!

Aklapper lowered the priority of this task from Normal to Low.Feb 20 2017, 1:07 PM

Upstream task https://secure.phabricator.com/T8510#202060 is only still open because

  • Maps and Discovery entered in the global search bar aren't in first position,
  • The "In Any" and "Not In" options are not always offered for exact project name matches in the "Tags" field of Maniphest's Advanced Search form. Workaround: Explicitly write not(wikidata) to get Not in: Wikidata.

In general the situation has improved a lot since this task was created, hence lowering its priority.

Addshore removed a subscriber: Addshore.Feb 20 2017, 4:03 PM