After T13049 this is relatively within reach, but we haven't seen other requests for it so I don't currently plan to pursue it.

I'm rolling this forward into T13049. See also D18919.

This is now in the wild, and nothing seems to have cropped up yet.

I'm pushing this here, yell if all your queries explode or what-have-ye.

We still get a tiny mess where administrators clicking "pin" might mean "pin by default for all users" or "pin by default for just me" but that's reasonable to clarify in the workflow.

Currently, users may hide or reorder builtin queries. With the simplest version of the plan above, users will lose that ability: builtin queries will always be visible (unless hidden by an administrator) and always at the bottom of the list.

Thanks for the explanation.

Named queries will get a new flag like isGlobal

I'm not proposing that, no. Here's exactly what I'm proposing:

At least, this is what I thought you were first proposing.

Basically the same UX as the home sidebar with home/dashboards.

OH yeah.

I wasn't planning to change the behavior of the dropdown, except that it would begin listing personal filters followed by global/default filters under "Saved Queries".

We're probably saying the same thing but maybe you wanted a simpler workaround first.

PHI29

Where's the other conversation?

I realize there are two conversations on this feature, I thought I was replying to the other thread.

Sorry, when I say "still" I mean like favorites on home.

I think we should still default search the top item.

I think we should still default search the top item. So if admins put "Super special search triggers" as the top item, that is the global default. One a user says OMG NO, and adds their first filter, that becomes their first item and thus their default search.

hmmmmmmmmmmm

Anyways, let's just go with "See all" in the header for now.

I'm also not sure how that works with pagination, like, do you update the URL so people can send links?

But that sounds like a lot of work.

Basically what I'd like is something that auto-pulls maybe 5 times, then just makes you click a button thereafter. That solves the footer issue, makes it nicer for people who only want 2-3 more pages, and then the edge case of "no really I want to keep reading past 500 results" have to click a button.

Let me marinate on it.

Sure, we can do that too.

Isn't auto-scroll with lots of JavaScript the right answer?

Ah, that makes sense. If there's some "good enough" way to get a button/link into these things today I'm happy to drop that in place while I'm in here, but we can just leave it for fiddling later too.

I don't think the current feed UI looks good in blue header, which is why I haven't moved it over. I'd need to fiddle with feed-view

@chad, I'd ideally like to put a "view more" on the feed on the project page so that the original issue here (wanting to page back in history) is easier to solve. This is what it looks like right now:

I'm going to call this resolved; T9979 is the survivor for Files and the Maniphest case is probably more involved (T6721).

👍🏼

We can also shrink/hide buckets from the panel context but keep them from the ApplicationSearch context. I think that's desirable -- if you go to /differential/ it's probably good to see all the bucket headers? Just not so good if you have a "Stuff to Review" panel on your home page.

IMHO, that's more likely what you want in most use cases anyway. I can imagine
quite a bit of confusion arising if you modify a query for a dashboard and it
unexpectedly modifies what shows up elsewhere.

We could conceivably do something like "edit this query" link from the panel, and have that take you to /application/query/wzyx/?panelPHID=asdf, and that generates a "save this query back to panel X" option in the UI.

Hmmm, not sure there is any path here, I seem to recall we can't allow editing of saved search queries without generating a new key? And if we generate a new key, we'd have to find all the Dashboards it's attached to?

They are not related. That search uses fulltext indexes (see T11922 / T11741 for recent discussion), not ngram indexes.

I don't think this is quite the same issue, but seems related, so I thought I'd err on the side of not creating a dupe.

I'm going to merge this into T9430 since they have the same upstream remedy. This query has largely been modern for some time, but I want to sort out T9430 before providing diffusion.commit.search.

Looked like there was some feed story grouping discussion in there

This is just a copy of a feature already discussed in T11432, right? Closing this in favor of that, which is already a better and more complete discussion of this request with context.

Partly, just haven't gotten there yet.

Looking through the code, looks like Maniphest doesn't use ngrams yet? Any reason?

I'm going to merge this into T10939, which answers this question in practice if not in theory.

T10579 mentions being able to query / build panels based on multiple states of a Diff or Audit.