just convinced that Phab search didn't work and feeling powerless over it

Amazon RDS is incredibly popular so although you haven't seen this request from other installs, my guess is that many are like we have been for the past 1.5 years - just convinced that Phab search didn't work and feeling powerless over it...I understand the squeaky wheel tends to get the oil, but it's worth maybe considering what % of installs use RDS since all of them will have this problem.

@epriestley as the former PM on Gmail I can tell you that for power users this was an incredibly valuable feature - and I've read from your docs that your typical user that your optimizing for is a power user that users Phab regularly. There's plenty of ways to make it discoverable. But I am not the PM here so all I can do is ask...

See also T4103.

@epriestley the UX problem here for us is that all of our employees are using global search when they don't realize it because it's top right when they go to the phab homepage, when in reality they only use Phab for Maniphest tasks. So asking every employee to manually configure these things doesn't solve this problem.

I believe it's all straight from MySQL. http://dev.mysql.com/doc/internals/en/full-text-search.html

Elasticsearch may also be a solution. Also, looks like we might be able to detect RDS installs by querying variables in MySQL.

Hi all, glad to see this issue is being looked at. Per my task in T10641, simply having "all documents" search show the same style of content as is seen in Maniphest search would speed up our day to day, as most people on our team use all documents search (unintentionally, as it is the default), even though all they really care about is Maniphest, and so their experience isn't great here (their impression is "Phabricator search isn't good" which I think is related not to functionality but discoverability and smarter default configurations).

Per conversation in T10589, I would like to echo @jhurwitz's request. In reality, both search for open & closed and open-only are use cases that exist. But in day-to-day work, even for QA, the very significant majority of use cases is for open only. In addition, w.r.t. the "closed tasks also" use case, the user behavior in response to "I didn't find what I looked for" is "refine my query" which is a natural human behavior that will cause these users to discover "oh, closed isn't checked". In addition, there is a visual cue when they see closed tasks that closed tasks look different, so the anticipated concern of "maybe the person searching will give up not seeing their closed item in the list" I believe is negligible (especially in face of the much more abundant concern of "omg there is so much closed stuff here...oh yeah, I need to ensure "open" is checked and "closed" is unchecked).

./bin/search index --force --all fixed this,.but i'm confused how some random tasks weren't indexed and some were

I suppose that'll work for maniphest/paste/projects/etc., but the most recent case I had in mind involved dashboard panel edit policies... :/

I don't anticipate ever building this. It would take months and only partially address a very narrow range of primarily operational use cases.

Quoting for the main page :

Thanks!! its worked now.

I don't think this is a good use of Tokens, which are primarily built for providing Phabricator with flavor. Your request is better suited for Facts (see T1562).

Another use case for this query would be to visualize the 'status' of subtasks on a workboard by filtering on 'blocked by Txxx'. For example, maybe some of the subtasks are Done while others are languishing in Backlog.

T10161 is a case of another install that selected ElasticSearch without a specific reason, based on a general belief that it is better in some intangible way.

I'm going to merge this into T5155, since the root issue here is philosophical opposition to the use of IAM Roles to manage credentials in the upstream. Two possible pathways forward outside of upstream support are:

Can you just use an IP-based access policy instead?

If you're using ElasticSearch on your install, can you let us know why you're choosing to configure it over the builtin MySQL search?

You can destroy the whole index, then reindex everything.

I think T4100 and design changes elsewhere sharply reduced the need for this, and don't anticipate pursuing it any time soon except perhaps as part of adjacent tasks like T5307 (and maybe T10034 and T4863).

T6281 is an older task discussing a possible deadlock under concurrency conditions in custom field reindexing. I think the versioning / locking approach above is probably the cleanest approach to resolving that, as well.

Broadly, to set expectations, this is a very low priority for the upstream and neither of us really have any familiarity with Elasticsearch, so I don't expect to move this forward for a long time.

As an alternative, I'd like to consider dropping upstream support for ElasticSearch entirely. We originally implemented it because Facebook wanted it and the project was more willing to implement and maintain things. However:

I suppose the "version number" I propose is a little tricky, because it won't be incremented if a user edits a comment -- this does not apply a new transaction. We could use a <MAX(transactionID), MAX(commentID)> version instead to catch edits.

The same behavior happens here as well. Typing watch causes the suggestion to be hidden, then adding d to make watchd results in the suggestion reappearing.

• rCALLSIGN autocompletes.
  • r substring, where "substring" is a substring of the repository name, jumps to matching results.

See also T9192.

I think this is a very low-impact change, but not an unreasonable one (the data is already available on the object, I think, and we do already show "Inactive", which is a somewhat similar state). This would make the list view marginally more useful in a tiny number of cases.

D14173 explains upstream attitudes toward exit codes in greater detail.

It seems that this is not limited to Maniphest, it applies to all search documents.