Throughput Analytics: Filter controls [FE]

Problem to solve

The Throughput Analytics feature (introduced under #229045 (closed)) is not very useful without the ability to apply filters that scope your perspective of the data.

Proposal

The Throughput Analytics feature should have a filter bar similar to Value Stream Analytics, which allows for filtering Merge Requests by:

• Assignee
• Author
• Labels
• Milestone
• Branch

Datepicker is covered in #229375 (closed) and we'll use a fixed timeframe until that issue is worked on.

added devopsmanage groupoptimize typefeature workflowdesign labels

marked this issue as related to #229045 (closed)

mentioned in issue #229267

marked this issue as related to #229267

mentioned in epic &3916

changed the description

@djensen @npost: Thanks for this issue, I added that we should ideally be able to support a NOT filter and also ideally be able to filter on branch (we'll use master by default).

I propose we leave Assignee and Author out of this iteration, we've discussed in the past skewing away from features that might make these tools used to evaluate individuals. We'll get this feature request but let's just focus on dogfooding and the features we need to accomplish that.

added to epic &3916

added Next Up priority1 workflowplanning breakdown labels and removed workflowdesign label

changed the description

@npost @jeremy I noticed that the screenshot in the description shows the revised pagination component. Just wanted to point out that this component doesn't exist in gitlab-ui yet. So I suggest to go with the currently available component which is https://gitlab-org.gitlab.io/gitlab-ui/?path=/story/base-pagination--default

Not to worry - removed from screenshot

Actually I meant to post this question in the Display data table of MRs in Merge Request Analytics issue.

changed the description

A couple more question regarding filtering:

Should we support multiple projects? Most of the filters we are about to introduce are project-specific, such as assignee, milestone, branch, ... So in case we want to enable users to select/exclude multiple projects, we would need a possibility to take this selection into account when fetching data for the other filter dropdowns (assignee, milestone, branch ...). Is this something our API currently supports? @djensen @ahegyi

Same problem with the NOT operator. If we want to exclude a certain project, how do we expect to fetch data for the remaining filter dropdowns?

So in case we want to enable users to select/exclude multiple projects, we would need a possibility to take this selection into account when fetching data for the other filter dropdowns

Can we reuse the existing filter bar endpoints? https://gitlab.com/groups/gitlab-org/-/merge_requests

The filters are not depending on each other. project_id or project_ids can be an extra parameter.

@ahegyi

The filters are not depending on each other. project_id or project_ids can be an extra parameter.

That means we would fetch labes, milestones, etc. per group but we wouldn't take the selected project id into account, is that right?

Yes, correct.

@ahegyi Would this still work if we had to support multi selection of groups, see #229045 (comment 380618816)?

No, AFAIK we don't support multiple groups with our standard finders.

Instance level finders are tricky and not working quite well. Try a label search on the dashboard: https://gitlab.com/dashboard/merge_requests

Should we move the project filter to a separate issue, but implement as a multi-project filter?

@djensen

I'm okay with this. Just want to point out that the impact of this will be that we can only display data for one group (with a given subset of filters) but won't be able to include/exclude certain projects ini the MVC. Are we all okay with this reduced scope for the MVC? @jeremy @npost

@wortschi: Yes

cc @npost

Perfect, here's the new issue to add a multi-project filter at the top of the Merge Request Analytics page: #229946 (closed)

mentioned in issue gitlab-org/manage/general-discussion#17138

mentioned in issue gitlab-org/manage/general-discussion#17256

@blabuschagne Can you please help estimate this issue?

@pshutsin or @ahegyi could you help estimate from the backend perspective?

I don't see a reason why we couldn't use the standard MergeRequest finder, so this should be pretty straightforward. I set the weight as 2. Feel free to comment if you have other suggestion.

@ahegyi Thanks for the input! I'm updating the weight to 4 based on your backend estimation and the frontend estimation in #230287 (closed)

I think we can start with standard MergeRequest finder as easy solution, I'm not sure it will be performant enough in long term.

marked this issue as related to #229820 (closed)

mentioned in issue #229946 (closed)

marked this issue as related to #229946 (closed)

changed the description

changed the description

added backend frontend labels

marked this issue as related to #230287 (closed)

set weight to 2

mentioned in issue #229820 (closed)

set weight to 4

added workflowscheduling label and removed workflowplanning breakdown label

I just moved this into workflowscheduling. I'm hopeful we can get this into %13.3, but it's blocked by the first second step, which is the chart, and the first step, which is the page.

mentioned in issue #230636 (closed)

assigned to @ahegyi

@mlunoe FYI - this is pilot feature where we could introduce the generic filter bar in.

Ok, I'll look into this. It seems that we can use the Generic filter bar implemented here (@ekigbo pointed us in this direction): !32961 (diffs). @ekigbo Do you see any challenges with using that generic filter bar here?

@blabuschagne is working on implementing the chart. I guess that issue would block this, right? [Update: Yes it is. It is already listed as blocking on the issue]. Also, do you see any challenges with using that generic filter bar here?

@mlunoe I'm not familiar with the Generic Filter Bar implementation but I've browsed the diff which you linked and I don't see any obvious challenges here. The component actually looks quite functional

@mlunoe I've created a separate issue for you for the implementation of a generic filter bar in #232465 (closed).

This issue here is more about integrating the component in the context of Throughput Analytics.

Thanks for creating the separate issue @wortschi ill add a comment there @mlunoe

assigned to @mlunoe

mentioned in issue #232357 (closed)

assigned to @blabuschagne and unassigned @mlunoe

marked this issue as related to #232465 (closed)

mentioned in issue #233312 (closed)

mentioned in issue #235068 (closed)

added workflowready for development label and removed workflowscheduling label

changed milestone to %13.4

removed Next Up label

added priority2 label and removed priority1 label

changed title from Throughput Analytics: Filter controls to [FE] Throughput Analytics: Filter controls

removed frontend label

set weight to 2

mentioned in issue #235984 (closed)

unassigned @ahegyi

@blabuschagne @ahegyi

I've split this into frontend and backend issues. This is the frontend portion, while backend is tracked in #235984 (closed)

I've also assigned the relevant weight to the individual issues.

/cc @djensen @jeremy

changed the description

@blabuschagne Ideally, we can already leverage the generic filter bar here that @mlunoe is going to implement.

Yes, it should work for this case! A few extra tokens, but that should be manageable. Take a look at this issue related MRs for progress on this: #232465 (closed) The short update is that it now handles its own state. The next step is to bring its own store, gracefully enhancing the application where it is being used.

Awesome, thanks for the info @mlunoe! Very excited to catch up and see all the great work that you've been doing with the filter bar!

@wortschi can we consider this issue workflowblocked until #232465 (closed) is resolved?

I would say that makes sense!

@blabuschagne Yes, agreed! I've applied the workflowblocked label