Hiding the organization's repository label set

[kebox7]

Feature Description

In some cases, there may be a need for centralized management of labels for the organization's repositories. Therefore, it would be nice to have settings to disable the ability to add predefined label sets for the organization's repositories.

Screenshots

[yp05327]

I'm sorry I don't understand your needs.
This default label set is for a quick start. If you added a new label, this quick start will disappeared.
You can add organization level labels for all repositories in organization's settings.
You can also add additional labels for the specific repositories.

[kebox7]

Hi @yp05327.

I'll try to clarify the situation. There is an organization, and we have added a set of labels for it.

Now we are adding a set of labels to the repository itself.

This will lead to duplicate labels and confusion. I would like to avoid such situations.

[yp05327]

I see. If some organization labels are same to the repo labels, then we need something like priority to avoid displaying same label twice. This is a good issue. 👍

[stuzer05]

I see. If some organization labels are same to the repo labels, then we need something like priority to avoid displaying same label twice. This is a good issue. 👍

Probably there shouldn't be a "crutch" to hide lables, instead administrators can remove duplicate labels from repo settings and call it a day. Extra logic on top of that is excess IMO

[yp05327]

That comment is about 4 month ago, and I want to update my comment.

Instead of hiding same labels, I think we can:

• avoid creating same labels
• quick move repo/org label to org/repo feature
  very nice feature in GitLab, I don't need to change the existing issue's label

But this maybe a breaking change.

[stuzer05]

That comment is about 4 month ago, and I want to update my comment.

Instead of hiding same labels, I think we can:

• avoid creating same labels
• quick move repo/org label to org/repo feature
  very nice feature in GitLab, I don't need to change the existing issue's label

But this maybe a breaking change.

No need to restrict anything, it's administrator's work to configure labels. Why add constaints, this should be human's job

[yp05327]

If you do not add some limitations, for experienced admins, yes, they can handle this.
But for fresh man, or someone not familiar with the management of this, they will be confused and that's why there's a issue here.

Same labels is confusing, and it depends on the admin's knowledge to handle it.
With a limitation, they can easily know how to design it. If you want to have bug label in both of them, like the original design, just rename org level labels into org/bug or something else, can also cover this use case I think, this is also a human's job.

[yp05327]

@lunny
how do you think about this comment: #7406 (comment)