Proposal: Organization labels #3559

New Issue

GiteaMirror · 2025-11-02T05:17:17-06:00

GiteaMirror commented

2025-11-02 05:17:17 -06:00

Originally created by @mrsdizzie on GitHub (Jul 10, 2019).

I'd like to implement labels on an organization level.

I think it should be pretty straight forward to add an org_id column to the label table and have it mostly work minus all interface updates/additions.

The way labels were implemented has them pretty coupled to repositories in code and language (compared to Webhooks, which seem to have been implemented without that limitation in mind and exist across repos and organizations ).

Many label functions currently are of the form GetLabelsByRepoID, getLabelInRepoByName, etc... and most of them rely on having a RepoID passed through.

Just want to get feedback if it is worth refactoring/renaming the following functions to take both a repoID and orgID (one always being nil) where appropriate since most of them would work the same otherwise and we would just want to do a lookup based on repoID OR orgID going forward:

877df0f9fb/models/issue_label.go (L155-L308)

Or if it is preferred to just have some code duplication and copy the existing functions and replacing repoID with orgID (it isn't too much here).

Duplicating them doesn't feel right, but hesitant to touch things that are working otherwise and just wanted some feedback as to which is preferred. The current API would remain the same for repo labels regardless so it would just be a refractor and not breaking change.

Originally created by @mrsdizzie on GitHub (Jul 10, 2019). I'd like to implement labels on an organization level. I think it should be pretty straight forward to add an ```org_id``` column to the ```label``` table and have it mostly work minus all interface updates/additions. The way labels were implemented has them pretty coupled to repositories in code and language (compared to Webhooks, which seem to have been implemented without that limitation in mind and exist across repos and organizations ). Many label functions currently are of the form ```GetLabelsByRepoID```, ```getLabelInRepoByName```, etc... and most of them rely on having a ```RepoID``` passed through. Just want to get feedback if it is worth refactoring/renaming the following functions to take both a repoID and orgID (one always being ```nil```) where appropriate since most of them would work the same otherwise and we would just want to do a lookup based on ```repoID``` OR ```orgID``` going forward: https://github.com/go-gitea/gitea/blob/877df0f9fbb3872f9af06067ea6371d14eecd3b3/models/issue_label.go#L155-L308 Or if it is preferred to just have some code duplication and copy the existing functions and replacing ```repoID``` with ```orgID``` (it isn't too much here). Duplicating them doesn't feel right, but hesitant to touch things that are working otherwise and just wanted some feedback as to which is preferred. The current API would remain the same for repo labels regardless so it would just be a refractor and not breaking change.

GiteaMirror added the issue/confirmed type/enhancement labels 2025-11-02 05:17:17 -06:00

GiteaMirror closed this issue

2025-11-02 05:17:18 -06:00

GiteaMirror commented

2025-11-02 05:17:19 -06:00

@lunny commented on GitHub (Jul 10, 2019):

How about a label template cross site or in organization?

@lunny commented on GitHub (Jul 10, 2019): How about a label template cross site or in organization?

GiteaMirror commented

2025-11-02 05:17:19 -06:00

@mrsdizzie commented on GitHub (Jul 10, 2019):

@lunny organizations could use a template same as a repo does now with this change. It would be just like repo labels now with the same interface except they would apply for the entire organization (and repos would still have separate labels too). Just like organization webhooks, but for labels.

So if an organization go-gitea made a label that was kind/bug then every repo for that organization could use that label and if you did a search for that label_id you would see all bug issues for tea,gitea,go-sdk,etc... and you would not have to make and search separate kind/bug label for each repo. This is currently very difficult for people that have many repos and just want to have a normal bugand feature tag for all of them AND to see all issues at once. Repo label search would still work as normal since it would limit issues to that repo_id.

Quick/Bad mockup like this:

So you could easily see issues in different repos with the same label.

@mrsdizzie commented on GitHub (Jul 10, 2019): @lunny organizations could use a template same as a repo does now with this change. It would be just like repo labels now with the same interface except they would apply for the entire organization (and repos would still have separate labels too). Just like organization webhooks, but for labels. So if an organization ```go-gitea``` made a label that was ```kind/bug``` then every repo for that organization could use that label and if you did a search for that ```label_id``` you would see all bug issues for tea,gitea,go-sdk,etc... and you would not have to make and search separate ```kind/bug``` label for each repo. This is currently very difficult for people that have many repos and just want to have a normal ```bug```and ```feature``` tag for all of them AND to see all issues at once. Repo label search would still work as normal since it would limit issues to that repo_id. Quick/Bad mockup like this: <img width="1196" alt="Screen Shot 2019-07-09 at 11 54 32 PM" src="https://user-images.githubusercontent.com/1669571/60939419-97b47380-a2a5-11e9-89aa-e7de3f8c6b27.png"> So you could easily see issues in different repos with the same label.

GiteaMirror commented

2025-11-02 05:17:19 -06:00

@lunny commented on GitHub (Jul 10, 2019):

When a repo has both self labels and organization labels, how to list them on issues labeling? Especially there are same labels.

@lunny commented on GitHub (Jul 10, 2019): When a repo has both self labels and organization labels, how to list them on issues labeling? Especially there are same labels.

GiteaMirror commented

2025-11-02 05:17:19 -06:00

@mrsdizzie commented on GitHub (Jul 10, 2019):

@lunny they could have both. Even now a repo lets you create two labels with the same name and information:

So it would probably be up to user not to put two labels with the same name on an issue (there shouldn't be any reason to really -- if you want to see only bugs for one repo the issue search will allow that even with an organization label). I suspect most people will not want to create labels with the same name for repo and org.

I also think on some views there can be a visual difference for organization labels to make it more clear, like this:

Users can select different colors too if they want or other ways to identify them. They would also be shown under a separate "organization" divider on the label assign list in issues so you can't easily pick the wrong one. There can probably be other little interface improvements too like adding an alt tag that says if a label belongs to an organization or repo.

@mrsdizzie commented on GitHub (Jul 10, 2019): @lunny they could have both. Even now a repo lets you create two labels with the same name and information: <img width="1140" alt="Screen Shot 2019-07-10 at 1 46 57 AM" src="https://user-images.githubusercontent.com/1669571/60943668-a8201a80-a2b4-11e9-90a7-f139e14923ec.png"> So it would probably be up to user not to put two labels with the same name on an issue (there shouldn't be any reason to really -- if you want to see only bugs for one repo the issue search will allow that even with an organization label). I suspect most people will not want to create labels with the same name for repo and org. I also think on some views there can be a visual difference for organization labels to make it more clear, like this: <img width="120" alt="Screen Shot 2019-07-10 at 1 40 29 AM" src="https://user-images.githubusercontent.com/1669571/60943377-db15de80-a2b3-11e9-8f18-782fd3e84a5d.png"> Users can select different colors too if they want or other ways to identify them. They would also be shown under a separate "organization" divider on the label assign list in issues so you can't easily pick the wrong one. There can probably be other little interface improvements too like adding an alt tag that says if a label belongs to an organization or repo.

GiteaMirror commented

2025-11-02 05:17:20 -06:00

@stale[bot] commented on GitHub (Sep 8, 2019):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

@stale[bot] commented on GitHub (Sep 8, 2019): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

GiteaMirror referenced this issue

2025-11-02 12:23:49 -06:00

[PR #3559] [MERGED] Update gogs to gitea migration manual #16995

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#3559