As a user, I want to be able to filter issues and merge requests by release, so that I can have a better overview of the items associated to a release (over one or more milestones).
Acceptance criteria
On the issues/merge requests search page, user should be able to filter items by releases.
All items linked to the milestones specified in the selected release should return in the page.
If milestone_1 and milestone_2 linked to a release_1, and the user selects release_1 AND milestone_3 in the filter, then no result should be returned.
Currently, it is not possible to filter the search pages by multiple milestones or by release. This issue proposes extending the search capability in the Issues and Merge Requests page, so that the user can have the flexibility to filter items by one/multiple Releases.
There cannot be milestones associated to a group. Project-level only.
Proposal
Add a new release filter to our "issues" and "merge requests" search page.
Example usage: release:v0.4. Behind the scenes, this filter would return all the items associated to the release's milestone(s).
Another thing to note is that when using the current (AND) functionality, if a user filters by release and by a specific milestone - only the items from the selected milestone should be returned.
Out of scope
In the future if the search supports OR a user can still use the new release type or filter by milestone..
Permissions and Security
Documentation
Testing
What does success look like, and how can we measure that?
It will be possible to filter issues and merge requests by multiple milestones.
We will be able to link the total count of open/closed issues and merge requests in a release to the filtered Issues view.
Category:Fuzz Testing
GitLab Ultimate
devops
application security testing
feature flag
frontend
fuzzing
coverage
group
dynamic analysis
missed:14.7
section
sec
type
feature
workflow
in dev
Category:Fuzz Testing
GitLab Ultimate
backend
devops
application security testing
direction
fuzzing
coverage
group
dynamic analysis
missed:14.3
missed:14.4
section
sec
type
feature
workflow
in dev
Category:Fuzz Testing
Deliverable
GitLab Ultimate
backend
devops
application security testing
direction
fuzzing
coverage
group
dynamic analysis
section
sec
type
feature
workflow
in dev
Category:Fuzz Testing
Deliverable
GitLab Ultimate
backend
devops
application security testing
direction
fuzzing
coverage
group
dynamic analysis
section
sec
type
feature
workflow
in dev
Category:Fuzz Testing
Deliverable
GitLab Ultimate
backend
devops
application security testing
direction
fuzzing
coverage
group
dynamic analysis
section
sec
type
feature
workflow
in dev
@ebaque@nfriend@ogolowinski I created this issue to track the updates in the the search page. Can you please make sure I added the right description, based on the latest decisions made on #31562 (closed)?
@ebaque@nfriend @rverissimo I updated the proposal in the description a bit.
We will move forward with creating a new "release" filter time for this iteration.
This should return all the issues from all the associated milestones.
If a user were to filter by release and milestone - the filter is equivalent to filtering by milestone
@ogolowinski Will we be tackling this in %12.4? Looks like this issue doesn't currently have a milestone.
Based on the Problem to solve section, we wouldn't necessarily have to have this complete in order to ship the improvements we're planning to the Releases page (#31289 (closed)).
@rverissimo @ogolowinski Looks good, I think adding a new "release" filter is the best way forward.
Should we update the title and the "User story"/"Problem to solve" sections to match the "Proposal" section? I.e. Make it possible to filter issues by multiple milestones > Make it possible to filter issues by releases?
Orit Golowinskichanged title from Make it possible to filter issues by multiple milestones to Make it possible to filter issues by Release
changed title from Make it possible to filter issues by multiple milestones to Make it possible to filter issues by Release
This looks good, thanks @rverissimo. I have one comment:
Another thing to note is that when using the current (AND) functionality, if a user filters by release and by a specific milestone - only the issues from the selected milestone should be returned.
Just to double check: if we have milestone_1 and milestone_2 linked to a release_1, and we select release_1 AND milestone_3, then no result will be returned. Agreed with that?
@rverissimo I don't think we need this acceptance criteria:
The search needs to be updated to support an OR (for example, release:%12.3 or release:%12.4).
Using an OR was one proposal when we were first looking into how to show all the issues associated to a particular release. The proposal was to OR all of the release's milestones together, like milestone:%12.3 OR milestone:%12.4.
However, adding in a release: filter removes the need to use an OR, since we can just do release:v1.2, for example.
@ogolowinski@nfriend@ebaque did this make planning? It's showing in the kickoff board because it has the direction label and %12.5 milestone, but it does not have the Deliverable or Stretch label so I'm unsure what that indicates. If it's not part of %12.5, the %12.5 milestone should be changed to %Backlog or another release.
@darbyfrey@ogolowinski question on this one - this seems like it would be dependent on associating milestones with releases, which missed %12.4. Is that not the case?
However, the backend pieces responsible for introducing the milestone <> release association is already live. Because of this, there's nothing currently blocking development on this issue (#32632 (closed)).
@ebaque As I'm implementing the frontend parts of this feature, I noticed that many of the filters (i.e. the milestone filter) provide "Any" and "None" options:
What are your thoughts about including these options in the release filter we'll be adding? (As shown in the screenshot above.)
As I have it implemented on my feature branch, instead of sending along a URL parameter like release_tag=v10.0, the frontend would send release_tag=Any or release_tag=None.
The most obvious issue I see is users won't be able to sort by a release based off a tag named Any or None. But my guess is that this would be very uncommon. We seem to have come to the same conclusion regarding the milestone filter (i.e. milestone_title=Any).
Hi @nfriend. I think it's a good idea to implement both Any and None options here. It makes sense to add them here.
I'll try to provide the backend for this before the end of this week, or for next week. However, I'm catching up on things I missed over the past couple of weeks, I still need to prioritize my tasks, so please let me know if you need this pretty quickly.
The main frontend piece has been merged (see !18761 (merged)) so you should be able to test this locally when working on the backend. Note the release: filter is hidden behind a :release_search_filter feature flag.
The only remaining piece that needs to merged from my side is !19315 (merged), which is in review with a maintainer and should be merged very soon. After that, I think all the frontend pieces of this feature will be complete - let me know if you find any issue while working on the backend.
@nfriend The backend MR has just been sent for code review. Please feel free to rebase on top of 32632-release-search-filter-be if you'd like to give it a try.
@ogolowinski I originally thought this MR didn't need any documentation updates, since our search filters are already well documented. But in the process of responding to you I found a page that mentions specific search filters, so I've created an MR to add the Release: filter to this list and sent it along to @marcia for review.
@ogolowinski That page is part of our "Contributor and Development Docs" - it's specifically about performing label filtering in code when developing new features for GitLab.