Hiding the organization's repository label set #13416

New Issue

GiteaMirror · 2025-11-02T10:41:43-06:00

GiteaMirror commented

2025-11-02 10:41:43 -06:00

Originally created by @kebox7 on GitHub (Aug 21, 2024).

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

Originally created by @kebox7 on GitHub (Aug 21, 2024). ### 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 ![Sample](https://github.com/user-attachments/assets/0c9cc4f0-92a8-4473-8bcb-dd253b713bd9)

GiteaMirror added the type/proposal label 2025-11-02 10:41:43 -06:00

GiteaMirror commented

2025-11-02 10:41:44 -06:00

@yp05327 commented on GitHub (Aug 21, 2024):

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.

@yp05327 commented on GitHub (Aug 21, 2024): 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.

GiteaMirror commented

2025-11-02 10:41:44 -06:00

@kebox7 commented on GitHub (Aug 22, 2024):

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.

@kebox7 commented on GitHub (Aug 22, 2024): Hi @yp05327. I'll try to clarify the situation. There is an organization, and we have added a set of labels for it. ![Organization level labels](https://github.com/user-attachments/assets/fcf9d805-bd16-40f7-93c7-7df75239b275) Now we are adding a set of labels to the repository itself. ![Repository level labels](https://github.com/user-attachments/assets/21434d86-2c48-4b11-916c-240eda7b925d) This will lead to duplicate labels and confusion. I would like to avoid such situations. ![Duplicate labels](https://github.com/user-attachments/assets/1d46c8f9-9a74-45aa-ba70-3c077901a1f0)

GiteaMirror commented

2025-11-02 10:41:44 -06:00

@yp05327 commented on GitHub (Aug 27, 2024):

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. 👍

@yp05327 commented on GitHub (Aug 27, 2024): 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. 👍

GiteaMirror commented

2025-11-02 10:41:44 -06:00

@stuzer05 commented on GitHub (Dec 9, 2024):

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

@stuzer05 commented on GitHub (Dec 9, 2024): > 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

GiteaMirror commented

2025-11-02 10:41:44 -06:00

@yp05327 commented on GitHub (Dec 9, 2024):

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.

@yp05327 commented on GitHub (Dec 9, 2024): 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.

GiteaMirror commented

2025-11-02 10:41:45 -06:00

@stuzer05 commented on GitHub (Dec 9, 2024):

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

@stuzer05 commented on GitHub (Dec 9, 2024): > 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

GiteaMirror commented

2025-11-02 10:41:45 -06:00

@yp05327 commented on GitHub (Dec 9, 2024):

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 commented on GitHub (Dec 9, 2024): 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.

GiteaMirror commented

2025-11-02 10:41:45 -06:00

@yp05327 commented on GitHub (Dec 9, 2024):

@lunny
how do you think about this comment: https://github.com/go-gitea/gitea/issues/7406#issuecomment-509918913

@yp05327 commented on GitHub (Dec 9, 2024): @lunny how do you think about this comment: https://github.com/go-gitea/gitea/issues/7406#issuecomment-509918913

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#13416