hmmmmmmmmmmm

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.

I think we should still default search the top item.

It hasn't worked this way since D12509. Here's where you specified the new behavior which I ultimately implemented, more or less: M1433#6594

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

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

Where's the other conversation?

PHI29

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

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

If you'd like to change the behavior of the dropdown, can you completely specify the new behavior you'd like?

OH yeah.

Basically make "All Documents" and "Current Applications" a menuitem, then also add a menuitem for saved query, which admins could build and set to top, which would make it the default globally. Then a user could instead add "All Documents" to their top, which would set it as their default.

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

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

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

• When you "Save Query", if you're an administrator, you'll get a new choice to either "Save as Global Query" or "Save as Personal Query".
  • Users who are not administrators will not get a new control, and this workflow will always work like "Save as Personal Query".
• Named queries will get a new flag like isGlobal, which is true for global queries and false for personal queries. This flag will be set for builtin queries and for "Global" queries saved by administrators. It will be cleared for personal queries saved by administrators, and for all queries saved by non-administrators.
• When you "Edit Queries", if you're an administrator, you'll get two separate sections: "Personal Queries" on top, and "Global Queries" below. You can reorder and edit these sections independently. You can not drag items between them, and can not mix the order (personal queries are always on top). Non-administrators will only see the "Personal Queries" section.
• By default, "Global queries" are populated with the builtin queries (for example, in Maniphest: Assigned, Authored, Subscribed, Open Tasks, All Tasks).
• Other existing queries will migrate to become "Personal queries".
• The left-hand navigation menu will show personal queries (in specified order), followed by global queries (in specified order).
• The search filter dropdown will show personal queries followed by global queries, all under "Saved Queries" or in separate similar sections like "Saved Personal Queries" and "Saved Global Queries".

Internally:

• I am not planning to use ProfileMenu to accomplish this. Here are some reasons I'm not planning to use ProfileMenu or MenuItem:
  • I think it doesn't make sense to, for example, add links or dashboards to pages like /maniphest/, or anything except queries.
  • I think the workflow for saving and managing queries would probably become more complicated if it went through ProfileMenu, and/or we'd have to make it much more complex on the backend.
  • I think the code for interacting with saved and named queries (for example, on Dashboards and in the global fulltext search dropdown) would become more complex if it needed to deal with an interstitial layer of MenuItem stuff.
  • To summarize: I believe there are no advantages to using ProfileMenu here (we don't want any of the features it provides) and significant disadvantages (UX gets much worse without a lot of polish, backend gets much worse if we polish the UX because it has to be a lot more complicated).
• I am not planning to make "Current Application" an available filter in the UI on /search/. This filter would not make sense: the current application on this page is always the "Search" application. The "Current Application" filter only makes sense as a piece of magic in the global dropdown because that lets it be accessed from other applications like Maniphest and Differential.

Named queries will get a new flag like isGlobal

(Mostly for consistency, this may actually be profilePHID or whatever, similar to PhabricatorProfileMenuItemConfiguration, although I think we're unlikely to use the flexibility this affords.)

Thanks for the explanation.

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.

I think it's probably OK that they are always visible. We haven't seen much feedback about this ("too much clutter at the bottom") for the home menu (for example, wanting to hide or fold global items). There's normally little real cost to users to have a few extra items in the menu that they don't care about too much.

I think it would also be relatively easy to let users continue to hide builtin (and potentially global) queries if they want. Basically, the "Edit Queries" UI would get two sections: one up top for reordering and deleting personal queries, and one on the bottom for disabling (but not reordering) global queries, for you personally. However, I'm not inclined to build this since I don't think it's too important -- most of the time it's just 2-3 extra links that aren't a big deal, and are generally useful enough that you probably click them occasionally even if they aren't your go-to queries. This UI would also get messier for administrators, since "disable" would have two possible meanings: disable for me personally or disable for all users by default. And it would create weird states where you "enable" a query which is globally disabled and it doesn't show up, unless we really turn this into a three-state "disabled", "enabled", "use server default" behavior.

Builtin queries will also move to the bottom of the list. This is potentially a little more of an issue. If users previously had a list like this:

Active
All
My Custom Query

...the change will reorder them:

My Custom Query
Active
All

...and they will no longer be able to drag "Active" above "My Custom Query" to make it the default. Instead, users would need to create a copy of "Active" ("My Custom Copy of Active") and put it in the list:

My Custom Copy of Active
My Custom Query
Active
All

I think we'd survive this, but I don't particularly love it.

One issue worth mentioning is that some queries, like /active/ in Differential, previously had magical hard-coded behavior and it was impossible to create a copy of them. I believe this is no longer the case, and that there are no longer any builtin queries with magic behavior, but it's possible I'm forgetting something.

We could mitigate this by revisiting the "top query is default" rule. I think this rule mostly works fine, but it's implicit, not completely intuitive, and we don't do much to teach it to the user. We could replace this with per-user default pinning, similar to how items can be pinned as defaults on Projects. Then a user could pin any visible item as their default explicitly, and we could migrate the existing queries to preserve behavior. In this case, the query order would still change, but the default query you get when you go to /maniphest/ would not.

I'm inclined to think this additional complexity is worthwhile because almost all users are exposed to this, "make a copy and drag it to the top" feels very hacky, and I think it's also a reasonable thing to want to be able to do.

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.

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