uh what

how could searching for a task's entire exact title possibly be useful

(See also T9979.)

haha I had a feeling this probably fell into the category of things that are in the process of being done a better/holistic way

Basically there's T6721, which is "allow users to do fulltext search on the title". I hope that's not really necessary now that we boost title matches in the normal results. I plan to maybe make fulltext search in Maniphest have a 'query relevance' order.

There's also T9979 and some related "maybe do exact substring search on titles", but I'm not sure this is useful with fulltext ordering.

This is a step beyond that, full matching for exact full titles. I don't know why anyone would ever know the exact, full title of a task without also knowing its task ID or PHID?

(Whoever asked for this definitely wanted a query for "browser" to return only tasks titled "browser" exactly, not tasks where "browser" appears somewhere in the title? Why do they know the entire exact task title but not its ID/PHID?)

Because people are filing tasks from external systems in some systematic way (consistent titles) not saving the ID, and then wanting to reference the task later.

The title has an ID in it already:

I think invariably this discussion will descend into "no you're doing it wrong" and I don't actually know which side I support anymore.

no no no no no no no no no no

why

why why

no no

Is Phabricator not a suitable replacement for a Jiffy Lube inventory terminal?

What is the plan for when I, purely out of spite, move to the east coast and get myself hired so I can create tasks with duplicate names filled with unrelated frivolous content?

Also why can't that asset have more than one "IMPI problem"? That title doesn't even look like it's guaranteed to be unique?

I assume everyone is fully aware of the caveats and just being lazy and not wanting to store the identifier they get back when they create the task? I will inquire further.

Materially, here are my concerns about this change:

• There is no legitimate reason to possibly ever do this.
• This field actually has a key on it, so query performance shouldn't be a problem (it would be for the LIKE %~ version of this).
• This field uses sort collation, so titles will be matched case-insenstively. This is probably not desirable when treating titles as unique keys, because it means that IDs "Asset 3ac" and "Asset 3AC" will be considered the same. It is reasonable to imagine that a system based on task titles as global unique identifiers also considers "3ac" and "3AC" to be reasonable, distinct unique identifiers.
• The most natural interpretation of title as someone learning this API for the first time is probably substring or fulltext match, not complete exact match. As a naive API consumer, I'd be surprised by this behavior. A better name might be entireExactTitle, maybe, hypothetically.
• Testing !$title will prevent users from querying for tasks with the title "0" (literal zero, no quotes). Use !strlen($title) instead.
• maniphest.search is the modern preferred method and maniphest.query will vanish at some point.
• You can implement the constraint into maniphest.search without upstreaming anything by writing a SearchEngineExtension. A reasonable example to follow might be PhabricatorSubscriptionsSearchEngineExtension. (You can't actually execute the query without modifying TaskQuery though.) But this would let you get halfway there without any upstream code.
• Saving the ID when the remote system creates the task is the correct way to do this.
• Using a custom field to store the remote object ID is also probably a reasonable way to do this, if some of this mess is because users are being bounced around between forms or something?

I think if this change comes upstream, it will be in the form of fulltext getting a smarter grammar, so you can search for something like title:~"exact full title" to mean "fulltext search of only the title field, performing a substring search which must match the entire field against the query". We're 3-4 steps away from this today, but a step or two closer than we were a couple weeks ago after stuff like D16938.

Oh god. I step away for 5 minutes and I'm now on the phacility hit-list.

Because people are filing tasks from external systems in some systematic way (consistent titles) not saving the ID, and then wanting to reference the task later.

The "systematic way" in at least one case just consists of giving the user a phab link with URL parameters to pre-fill in the fields. So the system doesn't get the ID returned to it. Yes, this is gross.

I assume everyone is fully aware of the caveats and just being lazy and not wanting to store the identifier they get back when they create the task

This is true.

I think we are doing this all downstream.

At worst we can just add another API method to our install, like, maniphest.reallysearchtitle