Fix labels dropdown with multiple same names
Currently in GitLab, in dropdown with labels, you can sometimes see multiple repeated labels with the same name or sometimes they are combined into one label but the UI tries to combine the colors.
This is confusing and not clear what's going on.
Proposal
In this first iteration, make sure that when you present any label dropdown in GitLab which allows you to assign labels (i.e. in issue / mr / epic sidebars), make sure to always have separate labels, even if they have the same name. I.e. make sure the dropdown always shows all unique labels.
And then when you assign the labels via the dropdown, make sure you are assigning the correct corresponding labels. So say there are three labels all called "Todo" in 2 separate projects (project labels), and in 1 group (group label), all three labels would show up in the dropdown separately. When you pick one to assign, it will assign that correct one. There will be no more color boxes with combined colors.
This will be suboptimal from a user experience (you don't know which label you are choosing), but that's okay for this iteration. (Since we aren't making things much worse, if at all).
Locations that need to be updated:
- filtered search bar
- issues list (group, project, dashboard)
- merge request list (group, project, dashboard)
- epic list (group, project, dashboard)
- sidebar
- issue page
- merge request page
- epic page
- issue board
- search bar
- board config
- bulk edit
- issues list
- merge request list
Future iterations (out of scope)
-
Make it obvious which label you are choosing to assign. So perhaps show project or group path for the label in the dropdowns.
-
Solve the problem of passing in label names in list view filters or API calls. Right now when you are in a list view filter, you can select a filter and the call will be based on label name. So there's no clarity on which label is actually used in the search. This is a related problem, can be solved separately here.
-
Any type of validation when choosing label names is out of scope. In this iteration, I (Victor) am assuming that labels are stored uniquely in the database, so that it's possible to at least reflect that uniqueness when assigning labels. And thus viewing unique labels per issue/mr/epic. We can address name collisions afterward.