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.
Designs
- Show closed items
Blocks
- #229267Next 7-12 releases
- #229946
Is blocked by
Relates to
Activity
-
Newest first Oldest first
-
Show all activity Show comments only Show history only
- Dan Jensen added devopsmanage groupoptimize typefeature workflowdesign labels
added devopsmanage groupoptimize typefeature workflowdesign labels
- Dan Jensen marked this issue as related to #229045 (closed)
marked this issue as related to #229045 (closed)
- Dan Jensen mentioned in issue #229267
mentioned in issue #229267
- Dan Jensen marked this issue as related to #229267
marked this issue as related to #229267
- Dan Jensen mentioned in epic &3916
mentioned in epic &3916
- Jeremy Watson (ex-GitLab) changed the description
Compare with previous version changed the description
- Contributor
@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.
2 - Jeremy Watson (ex-GitLab) added to epic &3916
added to epic &3916
- Jeremy Watson (ex-GitLab) added Next Up priority1 workflowplanning breakdown labels and removed workflowdesign label
added Next Up priority1 workflowplanning breakdown labels and removed workflowdesign label
- Jeremy Watson (ex-GitLab) changed the description
Compare with previous version changed the description
- Maintainer
@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 Collapse replies - Maintainer
Actually I meant to post this question in the Display data table of MRs in Merge Request Analytics issue.
Edited by Martin Wortschack
- Nick Post changed the description
Compare with previous version changed the description
- Maintainer
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?Edited by Martin Wortschack Collapse replies - Maintainer
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
orproject_ids
can be an extra parameter. - Maintainer
The filters are not depending on each other.
project_id
orproject_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?
- Maintainer
Yes, correct.
- Maintainer
@ahegyi Would this still work if we had to support multi selection of groups, see #229045 (comment 380618816)?
Edited by Martin Wortschack - Maintainer
No, AFAIK we don't support multiple groups with our standard finders.
- Maintainer
Instance level finders are tricky and not working quite well. Try a label search on the dashboard: https://gitlab.com/dashboard/merge_requests
- Author Contributor
Should we move the project filter to a separate issue, but implement as a multi-project filter?
- Maintainer
- Contributor
- Author Contributor
Perfect, here's the new issue to add a multi-project filter at the top of the Merge Request Analytics page: #229946 (closed)
1
- Dan Jensen mentioned in issue gitlab-org/manage/general-discussion#17138
mentioned in issue gitlab-org/manage/general-discussion#17138
- Jeremy Watson (ex-GitLab) mentioned in issue gitlab-org/manage/general-discussion#17256
mentioned in issue gitlab-org/manage/general-discussion#17256
- Maintainer
@blabuschagne Can you please help estimate this issue?
1 Collapse replies - Author Contributor
- Maintainer
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.
1 - Maintainer
@ahegyi Thanks for the input! I'm updating the weight to
4
based on your backend estimation and the frontend estimation in #230287 (closed) 1 - Maintainer
I think we can start with standard MergeRequest finder as easy solution, I'm not sure it will be performant enough in long term.
- Martin Wortschack marked this issue as related to #229820 (closed)
marked this issue as related to #229820 (closed)
- Dan Jensen mentioned in issue #229946 (closed)
mentioned in issue #229946 (closed)
- Dan Jensen marked this issue as related to #229946 (closed)
marked this issue as related to #229946 (closed)
- Dan Jensen changed the description
Compare with previous version changed the description
- Dan Jensen changed the description
Compare with previous version changed the description
- Dan Jensen added backend frontend labels
- Martin Wortschack marked this issue as related to #230287 (closed)
marked this issue as related to #230287 (closed)
- Adam Hegyi set weight to 2
set weight to 2
- Martin Wortschack mentioned in issue #229820 (closed)
mentioned in issue #229820 (closed)
- Martin Wortschack set weight to 4
set weight to 4
- Dan Jensen added workflowscheduling label and removed workflowplanning breakdown label
added workflowscheduling label and removed workflowplanning breakdown label
- Author Contributor
I just moved this into workflowscheduling. I'm hopeful we can get this into %13.3, but it's blocked by the
firstsecond step, which is the chart, and the first step, which is the page.Edited by Dan Jensen - 🤖 GitLab Bot 🤖 mentioned in issue #230636 (closed)
mentioned in issue #230636 (closed)
- Dan Jensen assigned to @ahegyi
assigned to @ahegyi
- Maintainer
@mlunoe FYI - this is pilot feature where we could introduce the generic filter bar in.
1 Collapse replies - Maintainer
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?Edited by Michael Lunøe - Maintainer
@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
1 - Maintainer
@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
.Edited by Martin Wortschack 1 - Maintainer
- Michael Lunøe assigned to @mlunoe
assigned to @mlunoe
- 🤖 GitLab Bot 🤖 mentioned in issue #232357 (closed)
mentioned in issue #232357 (closed)
- Martin Wortschack assigned to @blabuschagne and unassigned @mlunoe
assigned to @blabuschagne and unassigned @mlunoe
- Martin Wortschack marked this issue as related to #232465 (closed)
marked this issue as related to #232465 (closed)
- 🤖 GitLab Bot 🤖 mentioned in issue #233312 (closed)
mentioned in issue #233312 (closed)
- 🤖 GitLab Bot 🤖 mentioned in issue #235068 (closed)
mentioned in issue #235068 (closed)
- Jeremy Watson (ex-GitLab) added workflowready for development label and removed workflowscheduling label
added workflowready for development label and removed workflowscheduling label
- Jeremy Watson (ex-GitLab) changed milestone to %13.4
changed milestone to %13.4
- Jeremy Watson (ex-GitLab) removed Next Up label
removed Next Up label
- Jeremy Watson (ex-GitLab) added priority2 label and removed priority1 label
- Martin Wortschack changed title from Throughput Analytics: Filter controls to [FE] Throughput Analytics: Filter controls
changed title from Throughput Analytics: Filter controls to [FE] Throughput Analytics: Filter controls
- Martin Wortschack removed frontend label
removed frontend label
- Martin Wortschack set weight to 2
set weight to 2
- Martin Wortschack mentioned in issue #235984 (closed)
mentioned in issue #235984 (closed)
- Martin Wortschack unassigned @ahegyi
unassigned @ahegyi
- Maintainer
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.
4 - Martin Wortschack changed the description
Compare with previous version changed the description
- Maintainer
@blabuschagne Ideally, we can already leverage the generic filter bar here that @mlunoe is going to implement.
1 1 Collapse replies - Maintainer
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.
- Maintainer
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?
- Maintainer
I would say that makes sense!
- Maintainer
@blabuschagne Yes, agreed! I've applied the workflowblocked label
1
- Jeremy Watson (ex-GitLab) changed title from [FE] Throughput Analytics: Filter controls to Throughput Analytics: Filter controls [FE]
changed title from [FE] Throughput Analytics: Filter controls to Throughput Analytics: Filter controls [FE]
- Jeremy Watson (ex-GitLab) changed the description
Compare with previous version changed the description
- 🤖 GitLab Bot 🤖 added sectiondev label
added sectiondev label
- Martin Wortschack added workflowblocked label and removed workflowready for development label
added workflowblocked label and removed workflowready for development label
- Michael Lunøe assigned to @mlunoe and unassigned @blabuschagne
assigned to @mlunoe and unassigned @blabuschagne
- Maintainer
@blabuschagne I am taking over this issue as I have a draft MR that I can build on to add the filter controls to this page here: !40004 (merged)
Collapse replies - Maintainer
Amazing, thanks for owning this @mlunoe
1 - Maintainer
@blabuschagne You got it
- Michael Lunøe added workflowready for development label and removed workflowblocked label
added workflowready for development label and removed workflowblocked label
- Michael Lunøe added workflowin dev label and removed workflowready for development label
added workflowin dev label and removed workflowready for development label
- Michael Lunøe mentioned in merge request !40845 (merged)
mentioned in merge request !40845 (merged)
- Michael Lunøe added frontend label and removed backend label
- Michael Lunøe mentioned in merge request !40855 (merged)
mentioned in merge request !40855 (merged)
- Michael Lunøe mentioned in merge request !40948 (merged)
mentioned in merge request !40948 (merged)
- Michael Lunøe mentioned in merge request !41112 (merged)
mentioned in merge request !41112 (merged)
- Martin Wortschack changed the description
Compare with previous version changed the description
- Michael Lunøe mentioned in merge request !41898 (merged)
mentioned in merge request !41898 (merged)
- Nick Post mentioned in merge request gitlab-com/www-gitlab-com!62343 (merged)
mentioned in merge request gitlab-com/www-gitlab-com!62343 (merged)
- Dan Jensen mentioned in merge request !42284 (merged)
mentioned in merge request !42284 (merged)
- Michael Lunøe added workflowverification label and removed workflowin dev label
added workflowverification label and removed workflowin dev label
- Dan Jensen added workflowin review label and removed workflowverification label
added workflowin review label and removed workflowverification label
- Kushal Pandya closed with merge request !41898 (merged)
closed with merge request !41898 (merged)
- Kushal Pandya mentioned in commit 6b639561
mentioned in commit 6b639561
- Michael Lunøe added workflowverification label and removed workflowin review label
added workflowverification label and removed workflowin review label
- Michael Lunøe reopened
reopened
- Maintainer
Let's reopen this until it has been verified
- Mike Jang closed with merge request !42284 (merged)
closed with merge request !42284 (merged)
- Michael Lunøe changed milestone to %13.5
changed milestone to %13.5
- Michael Lunøe changed milestone to %13.4
changed milestone to %13.4
- Brandon Labuschagne added devopsmonitor label and removed devopsfoundations label
added devopsmonitor label and removed devopsfoundations label