Frontend allows to filter issues by 2 milestones although it is not possible

It's possible to filter by 2 milestones in the frontend although we don't allow filtering by multiple milestones.

The link you posted (https://gitlab.com/gitlab-org/gitlab-ce/issues?scope=all&utf8=%E2%9C%93&state=opened&assignee_username=filipa&milestone_title=8.17&milestone_title=8.16) has both milestone 8.16 & 8.17 so it will take the last one, in this case 8.16 which no issues exist for. We don't allow filtering by multiple milestones, there is an issue about doing OR filters.

closed

@iamphill the issue was about that

When I filter by 2 milestones

we should not allow to filter for 2 milestones in the Frontend, going to reopen and update the description. :)

reopened

@filipa i thought you meant you wanted to see both of them

changed title from Issues filter does not show issues although they exist to Frontend allows to filter issues by 2 milestones although it is not possible

@iamphill I did! ahah

But if we don't allow to filter by 2 milestones we should not allow the user to that :)

Yes @filipa, this is a bug and not a regression. First iteration of filtered search bar had this as a known side effect.

/cc @victorwu

@ClemMakesApps For a moment you got me thinking I had added the regression label eheh

mentioned in issue #25913 (closed)

changed milestone to %9.0

assigned to @psimyn

should this handle links that have multiples, or just prevent entering it in the searchbox?

I am thinking just handling dropdown selection is enough for most cases. Invalid links would still give invalid results

i.e. if I have

then try adding another

select the text of the first one

This issue is similar to #27293 (closed): Don't allow users to search for the same filters (Eg. Multiple label filters for the same label)

This issue: Don't allow users to search for filters that have a 1:1 relationship (Eg. Milestones)

Since we are dealing with a free form input, we cannot restrict the user from inputting multiple milestones because that user interaction will be quite strange. The main thing we can do is to just not populate it in the dropdown. Wdyt @cperessini @victorwu?

Having the dropdown click back to a previous token is quite strange imo

@ClemMakesApps : Are you talking about something like this where if I've already entered a milestone, milestones just don't show up anymore?

I think that's a pretty natural design.

That's what I'm thinking but I think @psimyn was proposing something else

@cperessini : Can you take a look and let us know the final design. Thanks.

I was spitballing ideas, filtering the list makes much more sense

mentioned in merge request !9406 (merged)

I think it makes sense to remove the option from the dropdown if you've already entered a filter that has a 1:1 relationship. That way we don't encourage people adding conflicting filters, but I have two questions:

• Is it worth it to introduce this limitation if we will have to remove it once we implement boolean operators? (you will be able to OR two milestones or two authors, for example)

• Users can still enter a duplicate filter by hand, right? @ClemMakesApps could there be a way to prevent the second filter from becoming a token?

@cperessini : I think it's worth it to do it. I want to do the boolean operators soon. But it will require BE work, and so it's not guaranteed we will get that in within the next few iterations, given the limited BE resources. So it's worth it to clean up these edge cases in the interim.

mentioned in issue #27293 (closed)

closed via merge request !9406 (merged)

mentioned in commit blackst0ne/gitlab-ce@53d4cad1

mentioned in merge request !10132 (merged)