GitLab 8.6: labels are duplicated in issue filter combobox

User Story

As a user on the dashboard issue list page, when I open the label combobox I see duplicates of each label and I would like to see only one copy.

Elaboration

We have global labels setup for new projects and individual labels setup for older projects. If #2651 (closed) were tackled, I do not think we'd have gotten into this situation.

@grzesiek this is the last one I've found today after upgrading to 8.6 as most things are working very well!

I wonder, if I delete the labels in my older projects, would they pickup the global labels like a new project? I'm half tempted to find a way to aggregate labels for old projects by going into the db.

@gsmethells Thanks for the report. Let's ask a frontend team about that, cc @jschatz1 @iamphill @annabeldunstone.

Added ~14281 label

Added frontend label

This looks fine on master & looks to of been done by @rymai in https://gitlab.com/gitlab-org/gitlab-ce/commit/ce44e5a787482e4d02cee007d35ab30ab651f6f8

@gsmethells Just to be clear, I think you're talking about the Dashboard Issues page.

Added ~12980 label

Reassigned to @alfredo1

I'm going to check this one

Assignee removed

I can't repro. Found an issue when trying to reproduce #14853 (closed)

@alfredo1 Can't reproduce? Should we close?

I don't think we should close this yet since I was not able to reproduce it.

Please don't close this. I have had this happen as well on v8.6.4.

NOTE: I have updated this comment to eliminate previous comment / screenshot related to labels not being displayed in v8.6.2 which appears not to be an issue in v8.6.4

@rymai yes, this is the dashboard issue page.

@gsmethells or @OnePressTech If you can give us steps to reproduce along with browser and operating system details we can try and reproduce this.

@jschatz1 - Not sure how I can assist to reproduce. Dead easy to reproduce. The issue is a design issue as per #2651 (closed). As long as labels are per-project, duplicate labels will appear in the dashboard Issues Filter-by-Label pull-down menu where the same label is added to multiple projects.

@OnePressTech Thank you!

@jschatz1 We use the exact same set of labels both in the global labels (for new projects we create) and in individual projects (for old projects that do not get the global labels). @OnePressTech is concurring with the "Elaboration" section I put in the description. I think #2651 (closed) is the driver of this issue.

@gsmethells I don't think you will see this issue anymore. Can you confirm @OnePressTech

Thanks for following up @jschatz1 but I'm not sure why you would think this. As long as there are project-based labels the dashboard label filter will show "duplicates". The only solution is to switch to global labels. @gsmethells am I missing something here...thoughts?

@OnePressTech I agree with you. I don't see what would have solved it yet. We are still seeing it now in "GitLab 8.6.5 e63f120e" at the dashboard level. We have matching "global labels" and "project labels", hence we see duplicates because of that.

@jschatz1 why do you believe this is resolved? What has changed in the code? Nothing has changed for us:

/cc @dzaporozhets

@gsmethells @OnePressTech I see the issue now. I was reading this wrong, my apologies. Let's schedule a fix for this. @skyruler or @dzaporozhets can you suggest a solution? I say if there are dups then we use parenthesis to clarify. Otherwise we leave them out. Or we use parens for the project page.

Added ~19492 label

@jschatz1 - Thanks again for your continued support in looking for solutions to this issue. In my mind, though, there is only one workable solution and that is to switch from project-based labels to global labels. Solutions such as parenthesis for dups won't improve matters because there is potentially one dup per project.

So let's assume we stay with project-based labels, we prefix the label id with the projectname so they are uniquely identifiable in the Dashboard dropdown menu...now imagine a 100 project repository...there will be 100 "xyzBUG" labels + 100 "xyzENHANCEMENT" labels + etc. You get the idea.

In general, a label is a project independent contextual descriptor so it is better supported as a global construct than a project-specific construct.

The alternative would be to move to a hybrid model whereby a label is project-specific until it appears in another project in which case it is then automatically converted to a global label and a global label that is only referenced from one project would be automatically converted to a project-specific label. Since labels are a url parameter there should be no issue in swtiching from project to global and back.

If it is a choice, though, between project-specific, global, or hybrid the simplest model that works would be global labels.

Just one man's two cents worth :-)

@gsmethells - thoughts?

I suspect the best approach would be to treat project labels that are string equal to a global label as if the project label did not exist.

The ultimate vision, I believe, is to resolve labels a la #2651 (closed). Anything else is a one-off patch of the real problem. I agree with @OnePressTech in that labels should be treated as global entities first when global labels exist and only if a project has a label that is not equivalent to a global label should the project level label be considered in whatever context it is in (combo box, Labels page, label picker on a Issue page, etc).

@jschatz1 I completely agree with using parenthesis to clarify. ><

@jschatz1 how do you anticipate parenthesis differentiating more than two instances of a given label?

@OnePressTech it won't differentiate two or more instances of a given label in one project but if they are in separate projects it will.

Milestone changed to 8.8

Reassigned to @alfredo1

@jschatz1 / @alfredo1 - Thanks Jacob but I'm showing my ignorance on this one. Is there some special significance to parentheses that I am unaware of within Ruby or markdown. I looked but I can't find anything. Could you clarify how a "bug" label in three projects would appear in a differentiable fashion using parentheses...thanks in advance.

Additionally, I'm not clear on your pro / con stance on the proposal to switch project-specific labels to global labels or a hybrid (as outlined above by @gsmethells and I). Differentiating labels is only one of two issues...the other is label management. It is unwieldy to manage individual repetitive labels like "bug" and "enhancement" etc on a 100+ project repository and a dashboard status filter for issues based on labels would be unwieldy...who wants a 100+ label menu...would you need to individually select 100 x "bug" labels if you wanted to see a summary of all the bugs in the repository?

It would be helpful if you could clarify your position on global vs. hybrid vs. project labels. Thanks in advance :-)

@OnePressTech I just read into the whole issue. I now understand where you are coming from.

@OnePressTech I've made an issue to fix this. https://gitlab.com/gitlab-org/gitlab-ce/issues/16555. Keep in mind we'll be playing around with different icon ideas there.

@jschatz1...#16555 (closed) is a slick solution to the dup label problem. Nice

Thanks @OnePressTech

Reassigned to @iamphill

mentioned in merge request !3963 (merged)

@OnePressTech @gsmethells We have a MR in for this !3963 (merged) which will close this issue. If you feel that there is more to be done feel free to create another issue and cc me. Like to keep it to 1 idea per issue.

Status changed to closed by commit ef842562

mentioned in commit ef842562

Works for me for now. Still got #2651 (closed) on my mind.

mentioned in issue #30271 (closed)