Just in my personal experience, I think it was sometime in the last 6 months that I realized Phabricator has a concept of "application search" and "global search", and that a lot of the searches I'd been doing were the latter and that's why they were so limited in functionality. I'd been using Phabricator for years and always had the sense that search didn't work very well, and that there were different forms I might get for it with different sets of fields, and it was unpredictable which one I'd get; but it wasn't until I became responsible for actually running Phabricator and started paying much closer attention to its concepts that I twigged to that pattern as the explanation for which searches got which form.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Apr 18 2017
Apr 13 2017
I'm only like 85% sure that D17667 really fixes things so yell if it still looks ~weird~.
(◍•ᴗ•◍)
\o/
Searching for ひらがな or 漢字汉字 or 漢字汉 now finds this task. Searching for 漢字 or 汉字 does not, but I think that's because they're under the minimum token length.
漢字汉
ひらがな
漢字汉字
漢字
汉字
Apr 12 2017
Thanks, much appreciated! 👍🏻
@chad thanks for sharing your perspective - I will try to share positive feedback as well. Hopefully that will allow the constructive feedback I have to be considered, as I have felt like the feedback and ideas I have shared have often been dismissed or had a very harsh response.
Users can customize their search (like I have below) or you can fork Phabricator to provide a different experience.
Your feedback is continually negative and tone deaf.
@chad I am trying to give constructive feedback to improve the product, including both the pain points and suggested improvements. I am not used to this kind of response to product feedback. It's unfortunate.
You've made it quite clear on multiple occasions Phabricator is a painful product to use for everyone at your company.
Our interest / problems related to this persist. I haven't been vocal as I don't know what else to do other than to share my feedback, but I continue to hear negative feedback internally in our company regarding this issue, per the description above.
This has been live for nearly two weeks without anything apparently exploding so we don't have any further acton planned upstream (although see T12450 for some followups). If you do run into issues, feel free to file new tasks describing them.
This has been open for about two years without a significant amount of additional confusion or interest, so I don't currently plan to change it.
I'm just going to merge this into T8646 which broadly discusses richer search results.
Apr 7 2017
Apr 5 2017
Apr 4 2017
Apr 3 2017
I implemented this recently but then pulled it out because ... project slug lookup is a gigantic mess right now.
Apr 2 2017
If you can run bin/whatever, policies no longer matter since you can bin/storage shell or any other number of dangerous things.
Maybe let bin/search commands target a specific service.
PhabricatorEnv::beginScopedEnv(); works anywhere if this makes more sense as, like, bin/search self-test or something rather than a unit test.
It would be nice to build a practical test suite instead, where we put specific documents into the index and then search for them.
Oh, I'm wrong. It hasn't been removed without replacement: there's a new path option for Elastic. I think there's probably a bug in indexExists() then, since it looks for 'phabricator' by name:
(This is all wrong, see below.)
In T12450#217586, @20after4 wrote:So I ran into one problem when deploying the latest code to WMF production. We now throw a setup error if we have a cluster with no readable hosts. It actually makes sense to have a cluster that is write-only so that setup error is bogus.
Mar 31 2017
Mar 30 2017
So I ran into one problem when deploying the latest code to WMF production. We now throw a setup error if we have a cluster with no readable hosts. It actually makes sense to have a cluster that is write-only so that setup error is bogus.
Mar 28 2017
bin/search init warns me that the index is "incorrect". It might be more clear to distinguish between "missing" and "incorrect", since it's more comforting to users to see "everything is as we expect, doing normal first-time setup now" than "something is wrong, fixing it".