Page MenuHomePhabricator

Saved Workboard Queries
Open, Needs TriagePublic


As a project manager, I'd like to have saved workboard queries to quickly jump between views.

Specifically I want a filter per team member and a filter for hiding subtasks ("show only tasks without open parents").

I am trying to use a single workboard to manage my team. During our stand-ups, I am using the advanced filter to highlight the tasks of a user. Performing the queries manually is error prone and is sometimes causing tickets to fall out of view. My team is also making use of ticket parenting so there are often many small tickets to track subtasks, so it is important to switch my view from subtasks to parent ticket. The advanced filter works very well; I just want to save my views. :)

Looking through old tickets there are a couple of similar requests, T4673 and T6681, which both seem to focus on showing closed tickets.

Event Timeline

Two workarounds you could use here are:

  • Bookmark the boards with the right filters applied: when you adjust the filter, the URL changes to preserve that filter.
  • Rather than using browser bookmarks, add the links to the project's menu as "Link" items, so you can follow links on the left-hand side (e.g., "Workboard", "Workboard (Subtasks)", etc).

Can you walk through why these aren't good fits for the problem you're facing? (For example: you have lots of different projects? Saving links is time consuming?)

If you could save your views, would you want to save them globally (i.e., all users can see the saved views) or personally (i.e., only you can see the saved views)?

If you could save your views, would you want them to be available from all workboards (i.e., saving a view makes it available everywhere) or unique to each workboard (i.e., each workboard might have different saved views)?

Outside of saving views, I've been mulling over the idea of having some sort of "quick filters" in the UI, which would apply some display filtering on top of the main query. The major issue I'd want to solve is that in-browser search pretty much turned to garbage (at least in Safari) on large workboards when we made the columns scroll internally. If I go to a workboard on this install like Diffusion and +F for a term in my browser, the highlights and scrolling interact in a destructive way which makes it difficult to identify results (and Command G to find the next result basically doesn't work). It would be a better experience if there was a "quick filter" where I could type in a search term and have the workboard just hide all the cards that don't match so I don't have to fight against the browser search feature.

To provide a specific example of this which reproduces today, at least: go to Diffusion here, search for "arcanist", and try to find T10945. This works alright in Chrome and Firefox but is total garbage in Safari, at least on my machine.

Possibly we can just find a way to fix this in Safari since the behavior is reasonable in other browsers (or get it fixed in the Webkit upstream), but I don't have terribly high hopes.

If we did build that, it might make sense to offer some other similar filters -- maybe UI buttons or just a sort of power-user query language in the same input ("assigned:epriestley"). I wouldn't want to pursue this before T10333, though.

(+@chad, who might also have thoughts here.)

T10333 might also solve at least some of this; presumably "filter by user" would become less important if you could "group by assignee", although if the board has a large number of tasks you might want to filter anyway.

This previously got some more substantive discussion in T6641, too. Particularly, see T6641#158940.

I think we have a basic query menu we could switch over to MenuItem, let users customize them per workboard like they can per project.

I am currently using bookmarks to workaround the issue. I never considered using the project menu for the workboard views. This would certainly suffice, but it doesn't feel like the right place for it.

I don't mean the project menu, I mean replacing the query menu on the work board with a confuigurable one like the favorites menu. I'd restrict it to task queires

I'm going to merge this into T12374.

If you have time, answering the questions in T12374#214870 on that task might be helpful. There are many possible implementations of this feature (e.g., per user/per workboard/global) and it's not clear to me which are desired from the use cases. It would also be helpful to understand what the major stumbling blocks are for using "bookmarks" and "saving queries to the menu" as workarounds (just cumbersome? Not the right scope/audience?).

This isn't a feature request with high user pain, as there are alternatives like adding bookmarks to the menu. Nevertheless, as some coworkers already asked me (independently) about how to save filters, there seems to be definitely something missing, that's obvious enough to be recongnized as suitable for the job. I think that they are aware of that kind of missing feature because of the "Save as default" menu entry in the filters menu. That raises the question if it isn't possible to save filters in general. Filters are also seen as an equivalent to queries and users already know how to save them. In fact, most of the coworkers who asked me, looked for a "Save query" button when creating a filter. So maybe that is already part of the answer how this feature should be implemented. I think, both ways would be reasonable solutions to implement this feature per user or per workboard. If we had to decide between them, we possible would go for personal filters, as it fits best with queries. Ideally one could chose or set policies. But that's probably too much for something, that can already be achieved through bookmarks. Definitely not a high priority. Just wanted to let you know that users seem to miss something more obvious here.

@epriestley we are using the "menu item" solution that you described above, and the primary remaining pain point is that when you click on a link, the menu highlights "workboard", which confuses some users, because they expect the link (i.e. the menu item they just clicked on) to be highlighted.

Our use case is having one big workboard for an Engineering project, and using queries to intersect Engineering with specific release or customer milestone tags. That lets us look at the appropriate subset of a workboard, while maintaining simple global state about the status of a task on the Engineering project's workboard. For example, we have a release tag named 11/9/18, and a link in the Engineering project's menu which takes you to Engineering's workboard with an additional filter on the 11/9/18 tag. Perhaps we are misusing something, just wanted to provide additional context if helpful for this discussion.