feat: Add sorting by exclusive label.

[telackey]

This PR adds a new sort option for exclusive labels.

While this has been looked at before (see the first comment below for a list), the goal of this particular approach was to do it in the most lightweight and flexible way possible, by making use of the existing exclusive label system. No changes are made to the Issue model.

For exclusive labels, a new property is exposed called "order", while in the UI options are populated automatically in the Sort column (see screenshot below) for each exclusive label scope.

This doesn't impose any particular scheme for prioritization, labeling, etc.; that's all up to the user.

[wxiaoguang]

There are different PRs for this problem and they conflict with each other (and the problem is pending for long time)

• Add advanced labels with priority Add advanced labels with priority #11669

• WIP: Weighted Issues WIP: Weighted Issues #32086

• Issue priority Issue priority #4823

• Add severity/priority feature for issues (Prioritize issues #2616) Add severity/priority feature for issues #2616 #10035

[dboreham]

Screen shot showing the feature:

[techknowlogick]

pinging @lafriks as this is likely relevant to your interests

[dboreham]

Proposed fix for #2616

[telackey]

Can you also display the order in the label list?

Yes, I can. But, how would you feel about it on the rendered label?

[telackey]

Can you also display the order in the label list?

Yes, I can. But, how would you feel about it on the rendered label?

Added

[telackey]

Non-DB indexers (search engines) are still problematic. No idea how to handle.

@wxiaoguang

Agreed, my proposal above (and in the current code) is to use the DB indexer for all sort-by-exclusive-label queries. While that isn't ideal for all cases, it does cover what I expect to be by far the most common use case, which is to click into a repo and then sort the open, active tickets by some sort of priority or status label. It also avoids sending any queries to external indexers which they cannot fully handle.

[wxiaoguang]

Hmm, I am neutral on this. What do maintainers think? also cc @lafriks

[lunny]

I have no better idea how to resolve it and I will not block this.

[lafriks]

Compared to my implementation this does have some bonuses (less code, no need for calculating/re-calculating issue priority) but also I don't know how it will perform on large db as join by like 'something/%' will most probably result in table full-scan

[telackey]

I don't know how it will perform on large db as join by like 'something/%' will most probably result in table full-scan

@lafriks

I don't think this will be an issue, as the LIKE portion of the query will be a filtering step after joining by label.id. The number of issue labels per-repo is likely to be small, no matter how large the repo or how great the number of issues, and so even if you did end up doing a scan across the small set of labels already matched by id, it is likely as fast or faster than an index (since linear scans are usually more efficient than an index is when dealing with small sets).

If an index did prove useful, it can be done fairly simply. Since this is a prefix-based LIKE, it can make use of a basic alphabetical index to turn it into a range scan. Something like:

create index labels_name_idx on labels ( name asc );

[telackey]

The latest commits have no functional changes, just merging in the last code from main.

[wxiaoguang]

Will take a look later when I get some time.

(ps: no need to update for every main branch commit 😄 )