Page MenuHomePhabricator

Searchable "Reference" custom field
Closed, DeclinedPublic

Description

Currently you can find an imported task by their reference, but this only works when using the related field in Maniphest's advanced search. Introducing "fl321" in the general search box in the header doesn't throw any results.

Would it be feasible to have the reference field indexed in the general search, so users could simply introduce i.e. "bz1234" in order to find the corresponding Phabricator task?

And even better, could be still throw a meaningful result if the user simply queries 1234 (since they might not be aware on the bz, rt, fl prefixes)?

Event Timeline

Qgil created this task.Oct 30 2014, 1:25 PM
Qgil raised the priority of this task from to Normal.
Qgil updated the task description. (Show Details)
Qgil added a project: Phabricator.
Qgil changed Security from none to None.
Qgil added subscribers: Jdforrester-WMF, chasemp, Qgil and 13 others.
Qgil renamed this task from Introducing reference number (ext_ref) in search should find the corresponding task to Introducing Bugzilla / RT / Reference number in search should find the corresponding task .Nov 5 2014, 11:32 PM
Qgil updated the task description. (Show Details)
Qgil moved this task from To Triage to Need discussion on the Phabricator board.

I'd much much rather that searching for "11" in Phabricator redirected to T11 (as tasks are the principle item in Phabricator that are numbered in denary). Is that an upstream request somewhere?

Qgil added a comment.Nov 6 2014, 12:04 AM

In Phabricator, "11" can be a task, a mockup, a paste, a diff... The first letter is essential.

What is being requested here is that the Reference custom field is indexed as well, and if possible

  • give it preference in search results, so "11" would propose first a task with a reference bz11 or rt11 etc.
  • tokenize the number, so 11 would find bz11.

I don't think this Wikimedia-specific problem is relevant upstream. Definitely not before we have a clear plan ourselves, but the implementation (if feasible) would most likely come with an extension.

In T991#19313, @Qgil wrote:

In Phabricator, "11" can be a task, a mockup, a paste, a diff... The first letter is essential.

Yes, of course, which is why I immediately justified my request with "as tasks are the principle item in Phabricator that are numbered in denary". 11 cannot be a commit (which is the only other thing that could vye for primacy).

What is being requested here is that the Reference custom field is indexed as well, and if possible

Yes, but these objectives cannot both be solved at the same time; either my request is met (in which case entering a number just takes you straight to that number, bypassing the search results) or yours is (in which case I am sad ;-)).

I don't think this Wikimedia-specific problem is relevant upstream. Definitely not before we have a clear plan ourselves, but the implementation (if feasible) would most likely come with an extension.

I agree that your request is Wikimedia-specific. Mine isn't, but is a counter-blocking request, so I noted it here.

Qgil added a comment.Nov 6 2014, 8:07 AM

Providing a good experience to users willing to find an old Bugzilla report by its number seems to be a more relevant case than saving to users the hassle of typing a "T" in front of a Phabricator task number.

All objects in Pabricator are preceded by a character since their inception. 11 is not T11, and it is good that all Phabricator users are aware of this.

I'd much much rather that searching for "11" in Phabricator redirected to T11 (as tasks are the principle item in Phabricator that are numbered in denary). Is that an upstream request somewhere?

No matter what, the result of the search query with just a number (i.e. "11") must be a list of relevant results and not a direct jump to a task. Users might be willing to find "11" as an actual number written down in the content of a task.

Therefore, your request for upstream could be that when users type i.e. "11" in the search, T11 would be suggested in a pop-up, just as it happens now when you type "T11". Maybe the other *11 could be suggested as well? This sounds like a more reasonable proposal for upstream, perhaps. Feel free to create a task for this, the main focus of this task is I want to find Bugzilla report 123 easily.

In T991#19368, @Qgil wrote:

No matter what, the result of the search query with just a number (i.e. "11") must be a list of relevant results and not a direct jump to a task. Users might be willing to find "11" as an actual number written down in the content of a task.

That is a determination for the Phabricator team as to how their product works. Thanks for the advice; I'll post this upstream.

Would it be feasible to have the reference field indexed in the general search, so users could simply introduce i.e. "bz1234" in order to find the corresponding Phabricator task?

+

Qgil renamed this task from Introducing Bugzilla / RT / Reference number in search should find the corresponding task to Searchable "Reference" custom field.Dec 11 2014, 10:39 AM
Aklapper lowered the priority of this task from Normal to Low.Jan 20 2015, 11:39 PM
Qgil added a comment.Jan 22 2015, 2:08 PM

Would it be feasible to have the reference field indexed in the general search, so users could simply introduce i.e. "bz1234" in order to find the corresponding Phabricator task?

+

Now we know that almost any user aware of the Reference field and "bz1234" is also aware that bz1234 == T3234. At least myself I only use search for Reference field values for old fab.wmflabs.org tasks, which happens only once every now and then.

Maybe we can get away without this feature?

seems not worth the headache at this point

Aklapper lowered the priority of this task from Low to Lowest.Jan 24 2015, 1:13 AM

This has been sitting for awhile now. Is anyone going to take this on?

This has been sitting for awhile now. Is anyone going to take this on?

Better question, is this a necessary feature at this point?

chasemp closed this task as Declined.Feb 17 2015, 5:15 PM
chasemp claimed this task.

This has been sitting for awhile now. Is anyone going to take this on?

Better question, is this a necessary feature at this point?

This was certainly made less important by your work on the bug N > T(N+2000) mapping. :)