@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.

@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.

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.

The high level need here actually just came up as recently as yesterday with our new senior product manager; he had no idea that there was a Maniphest-specific search and had instead been searching for maniphest tasks using global search (and was convinced Phab search was very limited due to this). Only upon me watching him do this search and advising him did he discover it. I've seen this issue several times now in our organization and I believe it contributes to the perception from some people internally that they have problems with Phab search.

FWIW I don't see this as something people would express interest in so it doesn't surprise me you haven't heard it from people, but if a user discovered it (e.g. there were an indicator below/during a search query as a power feature), I imagine they would use it. Just my 2 cents.

I'm saying for you, not for me. Nevermind, I'm gathering that having verbal conversations isn't a priority for you guys and you don't see the value in it. No problem.

Allow me to clarify: as a product manager I've found it incredibly useful to talk to both current paying customers as well as prospective paying customers and users of existing free products to learn about their needs and things that work well and don't work well in the spirit of improving our products. I find that qualitative conversations like this can be very useful, sometimes more useful than quantitative and written communication.

@epriestley we're actually not, we're a SaaS users of Phabricator, self-hosted (dev.doctor.com). We are indeed free installs, but my gut is that our needs are no different than those SaaS folks that pay you. I'm offering my time as a form of thank you for what you've offered for free, though :) if you're interested in talk to large-scale customers and learning what their needs are (and even what they might pay for, as an example).

Just wanted to chime in as a SaaS customer. :) We've been using Phab from a team of 15 to now we're about 100 people, and we use it for both our engineering teams as well as task management for our client services teams.

I am an admin w/full permissions, but even so I've tried just doing this on my own personal blog that I created myself and can't even do that.

Also, the workaround now is to do a search so it's not horribly broken, it's just not as great/fast/efficient for us as it used to be.

@chad yeah it's been a very long time, a year sounds plausible. I keep meaning to share this with you guys but I had been putting it off for a very long time as it hasn't been as important as other items in my world. One of the challenges with these sorts of things is that even though people in the field may be hitting the issue, they're usually trying to do something and in their workflow and don't bother sharing it... it was only when I asked around that people were like, "yeah, I miss how it used to be a long time ago..." etc.

@chad I see - my gut is that this is a common use case and that most teams will not take the time/energy to do this customization (or realize it's possible) but that they'd value having an easy way to see tasks as the primary use case of clicking a project name. Just my 2 cents.

@chad thanks - so sounds like you don't think this would be beneficial to everyone to have?

I appreciate that we can customize this, however this solution is not feasible for us as we have dozens of projects and add new ones regularly.

@epriestley I understand you have the setup check - my point is that for RDS users we skip this check when we see we can't do anything about it. And then months later it's forgotten about and we still draw that conclusion.

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

@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.

One final note, re: 2(b) which is the only item for which I did not file a new task, as you know, most people leave most defaults the same (when I was on the Gmail team it was 80-95% of people depending on the item). I'm hopeful that items like this could have defaults that are more common for the most common phabricator use case. I'm not an expert on what that most common use case is, but my gut is that is would be mostly Maniphest for software development, hence the suggestion.

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

@chad understood - I reviewed https://secure.phabricator.com/book/phabcontrib/article/feature_requests/ - was very informative, thanks! I also commented on T8660.

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

@epriestley @chad I just synced w/my team after doing a bit more research. There are a few items here - apologies ahead of time as I know each item below probably should be its own task, but feel free to separate as you deem fit.

@epriestley thanks for the detailed reply! I am now working with our DevOps person to change our configurations based on what you advise. Once we tackle all of this based on what you've mentioned, I'll update this task with examples (either suggested changes based on our UX or ways to improve discoverability for functionality that already exists but that we did not discover). Will be in touch in the coming days...

Cool, thanks!

Verified! You guys rock!

Even if it's not an everyone has a blog case, again, I can't imagine it's a common use case to regularly be switching blogs to post on. Again, this is just a convenience function (a "New Post" button that creates a new post for the last-posted-to-blog). Not required, just a nice to have.

Oh cool - that's a useful shortcut. But imagine that the primary use case is this sort of note taking where everyone has their personal blog, I anticipate that 95% of the time, people will be writing blog posts on the same blog they last wrote on. For the 15 people on our team, 100% of us only write on one blog which is our personal blog.

The only feedback I have is that since the "New Blog" button was added top Right (instead of, for example, "New Post" which would default to, say, the last blog that you posted to), I inadvertently created a new Blog when I meant to write a post.

As an aside, if you guys ever want insight from heavy Phab users, let me and Nico know! We're so deeply integrated now...we even automate the creation of Phab tasks via Salesforce to manage our entire Client Services team's work flow to onboard new clients. :)

Awesome :) yes, I don't see any of us caring about the slugs. In fact I remember it being a bit of a nuisance to do this because we'd have 15 people all with the slug of, for example, 12/10/2016, so we'd all have to make them unique. :)

We don't have external references to Phame, only internal references within Phame itself. So no need to have the old urls work in that regard. It's just that clicking the links in the phame UI itself is an important piece we'll need to work.

(the reason this issue is exacerbated for us is because the titles of all our posts are dates, which many folks use /'s for, so we have a ton of posts with this issue)

Yeah it's a critical part of our workflow :) back at Google there's this concept of "weekly snippets" that the whole company used to use and our engineering team here at Doctor.com models after that. It's really useful to get visibility into work. :)

@chad Hi Chad, so how can we remove it if we can't edit the post? Is there a workaround to edit the post? Or some manual database change we can make? We have literally hundreds of blog posts as we use this feature internally to track weekly work (hence the urgency as now our entire company has lost visibility into each other's work), so it would be a nightmare to do manually...

@epriestley thx Evan - please let us know if there's a workaround. We use these weekly blogs to track everyone's work so right now we can't monitor folks' work anymore.

<3 <3 <3

ahah nice! well-deserved :)

Oh I didn't know you guys only had 1 dev :( good to know - I'll try to work with Nicolast to see if we can identify the source of the bug. Regardless of the issue we love your product <3!

@chad thanks - interesting that I don't see any mention of the word "regression" - as feedback, I find that if regressions (i.e. something used to work but now it doesn't) aren't prioritized, that means that we have to expect anything can break at any time (maybe we should stop auto-updating Phab altogether if this is the case :( ).

Just wanted to check in on this - it's a really bad regression that's affecting our entire company internally (in bad ways because top priorities are going to the bottom). So would appreciate any help on this regression!

Yes, this is definitely new behavior - looks like a regression. And a pretty bad one because it results in someone prioritizing something to the top of the list and not realizing but the task itself goes to the bottom of the queue. So basically, prioritizing via dragging is totally broken.

If there's a "Closed" panel instead of being able to view the specifically closed items on a given board/milestone, this doesn't solve the original use case I filed this task for, namely to be able to tell which tasks have been closed on the given milestone for testing purposes so each closed item can be verified by QA.

Thanks for the quick reply.