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?

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.

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.

In T991#19309, @Jdforrester-WMF wrote:

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?

+

In T991#790795, @Nemo_bis wrote:

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

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

In T991#1031384, @chasemp wrote:

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