Scoped labels

[brechtvl]

Add a new "exclusive" option per label. This makes it so that when the label is named scope/name, no other label with the same scope/ prefix can be set on an issue.

The scope is determined by the last occurence of /, so for example scope/alpha/name and scope/beta/name are considered to be in different scopes and can coexist.

Exclusive scopes are not enforced by any database rules, however they are enforced when editing labels at the models level, automatically removing any existing labels in the same scope when either attaching a new label or replacing all labels.

In menus use a circle instead of checkbox to indicate they function as radio buttons per scope. Issue filtering by label ensures that only a single scoped label is selected at a time. Clicking with alt key can be used to remove a scoped label, both when editing individual issues and batch editing.

Label rendering refactor for consistency and code simplification:

• Labels now consistently have the same shape, emojis and tooltips everywhere. This includes the label list and label assignment menus.
• In label list, show description below label same as label menus.
• Don't use exactly black/white text colors to look a bit nicer.
• Simplify text color computation. There is no point computing luminance in linear color space, as this is a perceptual problem and sRGB is closer to perceptually linear.
• Increase height of label assignment menus to show more labels. Showing only 3-4 labels at a time leads to a lot of scrolling.
• Render all labels with a new RenderLabel template helper function.

Label creation and editing in multiline modal menu:

• Change label creation to open a modal menu like label editing.
• Change menu layout to place name, description and colors on separate lines.
• Don't color cancel button red in label editing modal menu.
• Align text to the left in model menu for better readability and consistent with settings layout elsewhere.

Custom exclusive scoped label rendering:

• Display scoped label prefix and suffix with slightly darker and lighter background color respectively, and a slanted edge between them similar to the / symbol.
• In menus exclusive labels are grouped with a divider line.

[brechtvl]

This is what it looks like in the issue sidebar:

And in the issue list label filter:

These are the only visual changes, everything else is in the behavior.

[brechtvl]

I changed label rendering for scopes now, and ended up doing a bunch of other changes to make it all fit together (see description above).

Also added support for removing scoped labels with alt key, both in single and batch issue editing, and improved the logic for batch editing.

Before:

After:

Sidebar menu:

[confusedsushi]

I wonder if this feature should be limited to :: as scope delimiter. Here we already use / to "group" labels and there is some infrastructure which deals with / as delimiter. Maybe the delimiter should be configurable?

Edit: "Here" refers to a instance of Gitea hosted in the company I am working for.

[brechtvl]

In this repository for example, the kind/ label is not mutually exclusive. So I'm not sure if you would want to use / as a delimiter, or at least you would have to change some of the label names either way.

I think there is something to be said for it not to be configurable, and let users explicitly change the label names where they want scopes. Short term it may be convenient to be able to change a single setting for all delimiters, but a common convention might also simplify things longer term when considering migration or federation. For label display the choice does not matter as the delimiter is not shown, it's only compatibility.

If it should be configurable I assume it would be at the organization level so it works for both organization and repository labels. Site-wide I guess would not work for a website like codeberg.

[wolfogre]

Agree:

• Support scoped labels
• Better UI for scoped labels
• Be mutually exclusive, but users can choose to turn it on or off.

Disagree:

• Use :: as delimiter, it looks ugly, I believe that's why we have to render it with strings.ReplaceAll(labelScope, "::", " \u203A ")
• Use a character as delimiter but render it to another character. I would be confused if you told me I should type "a::b" to search "a › b", so I prefer using / as delimiter, it has a natural meaning of separation.

Just my opinion.

[delvh]

Well, as it was said on the issue already:
That delimiter should be customizable.
I don't care if it is an instance-wide, org-wide, or repo-wide setting, so the easiest would probably be an instance-wide setting for now.
I don't have anything against using :: as default as long as it can be customized.

[brechtvl]

Well, as it was said on the issue already: That delimiter should be customizable. I don't care if it is an instance-wide, org-wide, or repo-wide setting, so the easiest would probably be an instance-wide setting for now. I don't have anything against using :: as default as long as it can be customized.

For a website like codeberg I think they would have no choice but to keep the delimiter as ::, to avoid breaking existing / labels. So effectively this customization would be for instances dedicated to particular software projects rather than more general purpose instances.

For my use case having it site-wide will be ok, just checking if that's understood and fine.

• Use :: as delimiter, it looks ugly, I believe that's why we have to render it with strings.ReplaceAll(labelScope, "::", " \u203A ")
• Use a character as delimiter but render it to another character. I would be confused if you told me I should type "a::b" to search "a › b", so I prefer using / as delimiter, it has a natural meaning of separation.

I agree :: looks ugly, the idea was to pick something that is already a convention in gitlab and not likely to conflict with existing labels.

So to satisfy everyone, I guess something like this is needed?

• Support site-wide customization of delimiter, defaulting to ::.
• Replace :: delimiter by something better looking as is done now, render other delimiters including / unchanged.
• For any delimiter, still find some visual way to indicate what is a scoped label or not. Simplest would be to just render the scope text with less contrast as is done now, but probably needs something more to be distinctive?
• Ideally make search for "status Resolved" also match "status::Resolved" somehow.

Two things to note regarding this:

• If you configure / to mean scoped labels, that means you will not be able to use / for other types of non-mutually exclusive labels. So you will have to find another delimiter for those.
• Do we ever want to make scoped label rendering look similar like gitlab as shown in [PROPOSAL] Issue groups - refer to GitLab #13117? This style can only work without showing any delimiter I believe.

[lafriks]

I completely agree on using / as group separator

[brechtvl]

I completely agree on using / as group separator

Are you saying you agree there should be an option to use / while :: remains the default? Or that / should be the default, despite it breaking compatibility with existing non-mutually exclusive labels that contain /?

[brechtvl]

So as a meta comment. I implemented this the way I think it should work, I'm happy to change it to how Gitea maintainers want it to work. And I hear that they want to (be able to) use / for scoped labels.

But there are design decisions to be made and compatibility issues to be considered when using /. And so it would be great to get some feedback on that, or an acknowledgement that these things are understood and not considered to be a problem.

[eeyrjmr]

So as a meta comment. I implemented this the way I think it should work, I'm happy to change it to how Gitea maintainers want it to work. And I hear that they want to (be able to) use / for scoped labels.

But there are design decisions to be made and compatibility issues to be considered when using /. And so it would be great to get some feedback on that, or an acknowledgement that these things are understood and not considered to be a problem.

Well since the aim is a post-render (ie eye candy) we don't see :: as it is now an arrow (or two tone as with gitlab)

So does it matter if :: is used in the label file ?

[brechtvl]

So does it matter if :: is used in the label file ?

There's two distinct reasons one might want to use something else:

• You already are using / as a convention for mutually exclusive scoped labels, and you want to turn them into real ones without having to do the work of renaming all those labels.
• You like the look of scope/name, and you want scoped labels to be rendered looking like that instead of the style of this PR or GitLab.

[lafriks]

I completely agree on using / as group separator

Are you saying you agree there should be an option to use / while :: remains the default? Or that / should be the default, despite it breaking compatibility with existing non-mutually exclusive labels that contain /?

I would say that / should be default (I would even say only option to not complicate things when migrating repositories between instances and future federation) and best option would be to allow to specify scope/group options whether group should be exclusive or not (but that could be implemented in future PR).

As for rendering I would maybe even prefer to render them as badges aka (group | label)

[brechtvl]

Ok, so what about this?

• Boolean "Exclusive" option per label that determines if the label is mutually exclusive with others in the same scope.
• No setting to configure the delimiter, always use /.
• Automatically render labels with / in them something like this, similar to GitLab but with a slant so it looks like forward slash.

[lafriks]

Ok, so what about this?

* Boolean "mutually exclusive" option per label that determines if the label is mutually exclusive with others in the same scope (maybe can think of a shorter name for the option).

* No setting to configure the delimiter, always use `/`.

* Automatically render labels with `/` in them something like this, similar to GitLab but with a slant so it looks like forward slash.

I fully support this 👍🏻

[lunny]

So does it matter if :: is used in the label file ?

There's two distinct reasons one might want to use something else:

• You already are using / as a convention for mutually exclusive scoped labels, and you want to turn them into real ones without having to do the work of renaming all those labels.
• You like the look of scope/name, and you want scoped labels to be rendered looking like that instead of the style of this PR or GitLab.

And we can also have another repository configuration to disable label group, so that those repositories just use / without group could keep compatible.

[lafriks]

Let's not complicate things, it will later just make it hard to use for migrating repositories and federation. If we really want to make it backward compatible we can just set non-explicit group option to already existing labels in migration

[brechtvl]

Okay, I'm confused now: My intuitive understanding is that unscoped labels cannot be exclusive. But I can select the checkbox even for them. It doesn't do anything. So, I think we should only enable it when the name matches /.*[^\/]\/[^\/].*/ with some JS, and disable it otherwise. The current approach simply confuses users.

I'll work on this.

I've managed to break to break the exclusive state:

Yes, it's not enforced that strictly, only on editing labels in an issue.

If this is needed we could display a warning "This label will be removed from N issues and pull requests" when you check Exclusive in the Edit Label popup.

XSS problems fixed

[brechtvl]

I did some improvements for the popup, but I'm out of time this weekend to do any more work on automatically removing conflicting exclusive labels, or solving the alt key problem.

[delvh]

Yeah, if we want to merge it into 1.19, I'm also fine with postponing the bugfix for another PR, as long as it is fixed before 1.19.0 is released.
As long it will still be fixed, I'm fine with it.
Will test it in a moment, and approve when it works.

[delvh]

… Almost there.

[delvh]

Oh yeah, what I forgot to mention previously:
For now, a simple "visual disable" is fine.
We can still think about disabling it using the disabled attribute instead of the CSS class later on.
Especially in terms of a11y, this change currently won't do anything at all, the checkbox can still be selected.

[brechtvl]

I intentionally just muted it because it's a bit annoying if you change the name to remove a / first, and then can't disable the checkbox after when it is no longer relevant. But I can see how that's not ideal for a11y.

[codecov-commenter]

Codecov Report

Merging #22585 (7411671) into main (feed1ff) will decrease coverage by 0.01%.
The diff coverage is 50.61%.

📣 This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more

@@            Coverage Diff             @@
##             main   #22585      +/-   ##
==========================================
- Coverage   47.36%   47.35%   -0.01%     
==========================================
  Files        1121     1121              
  Lines      150312   150440     +128     
==========================================
+ Hits        71192    71240      +48     
- Misses      70669    70748      +79     
- Partials     8451     8452       +1     

Impacted Files	Coverage Δ
routers/web/org/org_labels.go	0.00% <0.00%> (ø)
services/forms/repo_form.go	39.50% <ø> (ø)
services/repository/template.go	14.51% <0.00%> (-0.24%)	⬇️
routers/web/repo/issue.go	36.47% <16.66%> (-0.12%)	⬇️
routers/api/v1/org/label.go	79.12% <25.00%> (-1.08%)	⬇️
routers/api/v1/repo/label.go	81.54% <25.00%> (-0.99%)	⬇️
modules/templates/helper.go	43.82% <32.20%> (-1.13%)	⬇️
models/issues/label.go	55.95% <66.00%> (-0.73%)	⬇️
routers/web/repo/issue_label.go	37.19% <66.66%> (+0.01%)	⬆️
models/issues/issue.go	52.94% <100.00%> (+0.60%)	⬆️
... and 13 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[brechtvl]

Thanks everyone for the help in getting this done.

I've created #22974 to track and discuss the remaining work to be done.