Archive labels #11018

@acruzedeveloper commented on GitHub (Jun 20, 2023):

I want to give a try to this issue/feature. Please assign this to me. want to enhance the web skills.

@acruzedeveloper commented on GitHub (Jun 20, 2023): I want to give a try to this issue/feature. Please assign this to me. want to enhance the web skills.

GiteaMirror commented

@delvh commented on GitHub (Jun 20, 2023):

Yes, of course.
However, I'd like to know your opinion regarding the

Behavior unclear yet

paragraph before you start implementing it.

@delvh commented on GitHub (Jun 20, 2023): Yes, of course. However, I'd like to know your opinion regarding the > Behavior unclear yet paragraph before you start implementing it.

GiteaMirror commented

@delvh commented on GitHub (Jun 20, 2023):

want to enhance the web skills

By the way, what do you mean with web skills?
The feature as I've described it is rather a backend feature than a frontend feature.

@delvh commented on GitHub (Jun 20, 2023): > want to enhance the web skills By the way, what do you mean with `web skills`? The feature as I've described it is rather a backend feature than a frontend feature.

GiteaMirror commented

@acruzedeveloper commented on GitHub (Jun 20, 2023):

want to enhance the web skills

By the way, what do you mean with web skills? The feature as I've described it is rather a backend feature than a frontend feature.

I work on majorly golang and js. Just got started in open source contribution. 💯

@acruzedeveloper commented on GitHub (Jun 20, 2023): > > want to enhance the web skills > > By the way, what do you mean with `web skills`? The feature as I've described it is rather a backend feature than a frontend feature. I work on majorly golang and js. Just got started in open source contribution. 💯

GiteaMirror commented

@acruzedeveloper commented on GitHub (Jun 21, 2023):

Due to time shortage, I will share my initial finding soon, tomorrrow!.

@acruzedeveloper commented on GitHub (Jun 21, 2023): Due to time shortage, I will share my initial finding soon, tomorrrow!.

GiteaMirror commented

@acruzedeveloper commented on GitHub (Jun 22, 2023):

Understanding the requirements→

Understanding of ISSUES/LABELS/PROJECTS/MILESTONES

Labels are independents of ISSUES, PROJECTS and MILESTONES.
Issues are independents of Labels, PROJECTS and MILESTONES.

What I mean by independent is, they can be individually exist.

Milestone can be a part of project or as independent defined.
Similarly Project can be a independently defined.
Both milestone and project contains issues.
So Labels are the independent entity among all.

About milestone →
a. If any milestone is closed explicitly it does not mean the attached issues are closed automatically.
b. If all the issues and pr are completed or closed then the mile stone will automatically or implicitly completed.

That means from point a and b if mile stone is closed, then we need to archive the labels. No matter is issues are completed or closed state.

About project→
a. If any project is closed explicitly it does not mean the attached issues are closed automatically.

That means from point a is closed, then we need to archive the labels.

From point 1 and 2 above if any milestone and project close, then we need to also set in the prompt to archive the labels attached to them.

About Labels→

These are the independent entity can be attached to PR, ISSUES, MILESTONES and PROJECTS.
So we can individually archive each and every label explicitly if we want. It will not make affect on the status [open/close] of PR, ISSUES, MILESTONES and PROJECTS.
That means PR, ISSUES, MILESTONES and PROJECTS can have archived labels. But in search functionality we have to check the “Include Archive Option”.

Solution Proposed →

Backend side →
- Add a checkbox archive(d) on the edit label screen (and to the PATCH API route /repos/{owner}/{repo}/labels/{id})
- When editing a label and it is newly archived, store ArchivedUnix timestamp(now) inside the db
- When a label is edited and no longer archived, set the archived timestamp to 0

2 Frontend side →

Add a archive checkbox in the add label modal box. Similarly with edit modal box.

Issues Listing on the UI →

when viewing a specific issue/ the issue list, display all labels on all issues #1

Yes, by default all the issues should be populated in the list including archived labels tagged issues too.
Motivation → we are on the landing page of issues and we should show all the issues including archived labeled.

Behaviour unclear yet:
when assigning labels to an issue, should we only suggest unarchived labels? #2

Yes, by default we should only suggest the unarchived label. We should provide an option “Exclude Archive Label” enabled by default. If the “Exclude Archive Label” is set unchecked we should display the archived labels as well.

Special use case to keep “Exclude Archive Label” in the search list of label as below. As we have currently 3 version of Gitea to maintain 1.19, 1.20 and 1.21rc, there will be bug fixes in we need to release the minor version . So taking the “backport/*” labels, if any new maintainer comes and he/she doesn’t have understanding of labels , which label should be tagged to the issue or pr. Obviously we have archived the labels of old versions. So if we select couple of issues in the issue-action menu we should give this option to user to see the unarchived labels as well.

in both these cases, these are the available approaches: #3

add a checkbox include archived labels inside the suggestion box that is de-selected by default, and re-triggers the search when changed. Needs a lot of UI changes

do not suggest them unless they are entered exactly into the search field. Doesn't need a lot of UI changes except it should only be shown when the name matches exactly

In this case lets go with option 2. Yes UI changes will be less and but we give the user an option to “Exclude Archive Label” in the search list as well as in issue-action menu to ease the work. Motivation is the same as #2.

do we count the number of unarchived labels or the number of all labels as the number of labels?

No, we don’t need count number of unarchived labels or total labels. But if we want we can put a filter in label screen to filter this number. But I am highly encourage not to put in ISSUE/Milestone/PR/Project screen. It will be overkill. And we count the number of issues/pr tagged a particular label. Not the label itself.

PS:

I have two more scenario.

If any milestone reopen then do we need to provide the option to unarchive the labels as well or it should be implicit that we should unarchive the label of those milestone.
Similar goes with project.

I am open for all suggestions and feedback. will be grateful.

cc / @delvh

@acruzedeveloper commented on GitHub (Jun 22, 2023): ## Understanding the requirements→ ### Understanding of ISSUES/LABELS/PROJECTS/MILESTONES * Labels are independents of ISSUES, PROJECTS and MILESTONES. * Issues are independents of Labels, PROJECTS and MILESTONES. > What I mean by independent is, they can be individually exist. * Milestone can be a part of project or as independent defined. * Similarly Project can be a independently defined. * Both milestone and project contains issues. * **So Labels are the independent entity among all.** 1. About milestone → a. If any milestone is closed explicitly it does not mean the attached issues are closed automatically. b. If all the issues and pr are completed or closed then the mile stone will automatically or implicitly completed. That means from point a and b if mile stone is closed, then we need to archive the labels. No matter is issues are completed or closed state. 2. About project→ a. If any project is closed explicitly it does not mean the attached issues are closed automatically. That means from point a is closed, then we need to archive the labels. > From point 1 and 2 above if any milestone and project close, then we need to also set in the prompt to archive the labels attached to them. 3. About Labels→ * These are the independent entity can be attached to PR, ISSUES, MILESTONES and PROJECTS. * So we can individually archive each and every label explicitly if we want. It will not make affect on the status [open/close] of PR, ISSUES, MILESTONES and PROJECTS. * That means PR, ISSUES, MILESTONES and PROJECTS can have archived labels. But in search functionality we have to check the “Include Archive Option”. ### Solution Proposed → 1. Backend side → - Add a checkbox `archive(d)` on the `edit label` screen (and to the `PATCH` API route `/repos/{owner}/{repo}/labels/{id}`) - When editing a label and it is **newly** archived, store `ArchivedUnix timestamp(now)` inside the db - When a label is edited and no longer archived, set the archived timestamp to `0` 2 Frontend side → - Add a archive checkbox in the add label modal box. Similarly with edit modal box. #### Issues Listing on the UI → > when viewing a specific issue/ the issue list, display all labels on all issues \#1 Yes, by default all the issues should be populated in the list including archived labels tagged issues too. Motivation → we are on the landing page of issues and we should show all the issues including archived labeled. > Behaviour unclear yet: when assigning labels to an issue, should we only suggest unarchived labels? \#2 > Yes, by default we should only suggest the unarchived label. We should provide an option “Exclude Archive Label” enabled by default. If the “Exclude Archive Label” is set unchecked we should display the archived labels as well. _Special use case to keep “Exclude Archive Label” in the search list of label as below. As we have currently 3 version of Gitea to maintain 1.19, 1.20 and 1.21rc, there will be bug fixes in we need to release the minor version . So taking the “backport/*” labels, if any new maintainer comes and he/she doesn’t have understanding of labels , which label should be tagged to the issue or pr. Obviously we have archived the labels of old versions. So if we select couple of issues in the issue-action menu we should give this option to user to see the unarchived labels as well._ > in both these cases, these are the available approaches: \#3 > > 1. add a checkbox `include archived labels` inside the suggestion box that is de-selected by default, and re-triggers the search when changed. Needs a lot of UI changes > 2. do not suggest them unless they are entered **exactly** into the search field. Doesn't need a lot of UI changes except it should only be shown when the name matches exactly In this case lets go with option 2. Yes UI changes will be less and but we give the user an option to “Exclude Archive Label” in the search list as well as in issue-action menu to ease the work. Motivation is the same as \#2. > do we count the number of unarchived labels or the number of all labels as the number of labels? > No, we don’t need count number of unarchived labels or total labels. But if we want we can put a filter in label screen to filter this number. But I am highly encourage not to put in ISSUE/Milestone/PR/Project screen. It will be overkill. And we count the number of issues/pr tagged a particular label. Not the label itself. #### PS: I have two more scenario. 1. If any milestone reopen then do we need to provide the option to unarchive the labels as well or it should be implicit that we should unarchive the label of those milestone. 2. Similar goes with project. I am open for all suggestions and feedback. will be grateful. cc / @delvh

GiteaMirror commented

@delvh commented on GitHub (Jun 22, 2023):

Okay, I think I got the gist of what you're trying to say.
As I understand your message, you basically reference two different states at the same time, namely the optimal behavior you expect projects, milestones, and labels to have, and the solution you want implemented.

Here are my thoughts about that:
1.

No, we don’t need count number of unarchived labels or total labels

I meant this counter:

But apparently, I was too used to GitHubs appearance when writing the original message as I thought of this label counter that Gitea doesn't have (yet?):

That has also shown me an edge case I haven't considered yet:
We should show archived labels on the labels page in a subsection that is hidden by default (i.e. a <details><summary>Archived labels</summary>…</details>) as you rarely want to edit them once they are archived.

Behaviour unclear yet:
when assigning labels to an issue, should we only suggest unarchived labels? https://github.com/go-gitea/gitea/pull/2

Yes, by default we should only suggest the unarchived label. We should provide an option “Exclude Archive Label” enabled by default. If the “Exclude Archive Label” is set unchecked we should display the archived labels as well.

Special use case to keep “Exclude Archive Label” in the search list of label as below. As we have currently 3 version of Gitea to maintain 1.19, 1.20 and 1.21rc, there will be bug fixes in we need to release the minor version . So taking the “backport/*” labels, if any new maintainer comes and he/she doesn’t have understanding of labels , which label should be tagged to the issue or pr. Obviously we have archived the labels of old versions. So if we select couple of issues in the issue-action menu we should give this option to user to see the unarchived labels as well.

in both these cases, these are the available approaches: https://github.com/go-gitea/gitea/pull/3
add a checkbox include archived labels inside the suggestion box that is de-selected by default, and re-triggers the search when changed. Needs a lot of UI changes
do not suggest them unless they are entered exactly into the search field. Doesn't need a lot of UI changes except it should only be shown when the name matches exactly

In this case lets go with option 2. Yes UI changes will be less and but we give the user an option to “Exclude Archive Label” in the search list as well as in issue-action menu to ease the work. Motivation is the same as https://github.com/go-gitea/gitea/pull/2.

I think something got "lost in translation" there:
I meant that as "we have 2 cases to consider with the same 2 available solutions each time".
I don't quite understand why you are suggesting both UIs for different situations (I think? I have huge problems understanding these paragraphs)

You won't implement the auto-archival in the initial PR, correct?
After all, the smaller a PR, the more likely it is to get merged.
Additionally, reviewers will likely oppose your proposed automation (which in the worst case blocks a PR from being merged forever) and requires a lot of further discussion before being implemented.
So, it's better to extract it into a follow-up PR, if at all.
I haven't quite understood how exactly you define which labels should be archived once a milestone is closed.
You of course don't want to close all labels that appear in any issue of the milestone.
So, you would probably need to store a list of milestone-specific labels to close once the milestone is closed., or what do you suggest there?
Phew, I think I got everything.

@delvh commented on GitHub (Jun 22, 2023): Okay, I think I got the gist of what you're trying to say. As I understand your message, you basically reference two different states at the same time, namely the optimal behavior you expect projects, milestones, and labels to have, and the solution you want implemented. Here are my thoughts about that: 1. > No, we don’t need count number of unarchived labels or total labels I meant this counter: ![grafik](https://github.com/go-gitea/gitea/assets/51889757/546d75b9-c32c-445c-9fee-29148098ed6b) But apparently, I was too used to GitHubs appearance when writing the original message as I thought of this label counter that Gitea doesn't have (yet?): ![grafik](https://github.com/go-gitea/gitea/assets/51889757/35c39695-69f8-4262-8cbc-96b5c2b00fa4) That has also shown me an edge case I haven't considered yet: We should show archived labels on the labels page in a subsection that is hidden by default (i.e. a `<details><summary>Archived labels</summary>…</details>`) as you rarely want to edit them once they are archived. 2. > > Behaviour unclear yet: when assigning labels to an issue, should we only suggest unarchived labels? https://github.com/go-gitea/gitea/pull/2 > Yes, by default we should only suggest the unarchived label. We should provide an option “Exclude Archive Label” enabled by default. If the “Exclude Archive Label” is set unchecked we should display the archived labels as well. > Special use case to keep “Exclude Archive Label” in the search list of label as below. As we have currently 3 version of Gitea to maintain 1.19, 1.20 and 1.21rc, there will be bug fixes in we need to release the minor version . So taking the “backport/*” labels, if any new maintainer comes and he/she doesn’t have understanding of labels , which label should be tagged to the issue or pr. Obviously we have archived the labels of old versions. So if we select couple of issues in the issue-action menu we should give this option to user to see the unarchived labels as well. > > in both these cases, these are the available approaches: https://github.com/go-gitea/gitea/pull/3 add a checkbox include archived labels inside the suggestion box that is de-selected by default, and re-triggers the search when changed. Needs a lot of UI changes do not suggest them unless they are entered exactly into the search field. Doesn't need a lot of UI changes except it should only be shown when the name matches exactly > In this case lets go with option 2. Yes UI changes will be less and but we give the user an option to “Exclude Archive Label” in the search list as well as in issue-action menu to ease the work. Motivation is the same as https://github.com/go-gitea/gitea/pull/2. I think something got "lost in translation" there: I meant that as "we have 2 cases to consider with the same 2 available solutions each time". I don't quite understand why you are suggesting both UIs for different situations (I think? I have huge problems understanding these paragraphs) 3. You won't implement the auto-archival in the initial PR, correct? After all, the smaller a PR, the more likely it is to get merged. Additionally, reviewers will likely oppose your proposed automation (which in the worst case blocks a PR from being merged forever) and requires a lot of further discussion before being implemented. So, it's better to extract it into a follow-up PR, if at all. 4. I haven't quite understood how exactly you define which labels should be archived once a milestone is closed. You of course don't want to close all labels that appear in any issue of the milestone. So, you would probably need to store a list of milestone-specific labels to close once the milestone is closed., or what do you suggest there? 5. Phew, I think I got everything.

GiteaMirror commented

@acruzedeveloper commented on GitHub (Jun 25, 2023):

I appreciate your feedback, and I agree with points 1, 3, and 4 as you mentioned. Regarding point 2, I should have attach the screenshots earlier. It would have been helpful to provide visual evidence from my side.

I have carefully considered your feedback and taken into account your points, along with my own thoughts. Together, we have reached the following discussion till now.

According to the github ui on issues and pr view we can add the labels count.
Github ui:

If you see the milestone only open milestone count are there.

Github does not have archival label feature yet for labels.

For Gitea UI :
Total number of labels will be good to show. Issue/Pr screen.

Current screen of gitea:

After added count:

The count is total number of labels including archived.

In the current label screen in gitea →

Github UI:

There is no count on label button, and total count is down.

After archival labels features in gitea →

Label title will remain same.
We will categories the label count into non archived label and archived label.
1. Non archived label → <count> label , where is count is the number of non archived labels and "label" as the text for count.
2. Archived label → <count> archived, where is count is the number of archived labels and "archived" as the text.
For example

Will be anchor tag grey in color. “2 archived” will be a separate tab in Label window in gitea as below screen shot

Current label drop down in gitea when not selecting any issue/pr →

When adding archive functionality when not selecting any issue →

When clicking on issue and then inside “Label” menu we will list the archived labels at the end.

Implementation Proposed →

Backend side →
- Add a checkbox archive(d) on the edit label screen (and to the PATCH API route /repos/{owner}/{repo}/labels/{id})
- When editing a label and it is newly archived, store ArchivedUnix timestamp(now) inside the db
- When a label is edited and no longer archived, set the archived timestamp to 0

2 Frontend side →

Add a archive checkbox in the add label modal box. Similarly with edit modal box.

New Label→

Edit Label→

I am open for further discussion.

cc// @delvh

@acruzedeveloper commented on GitHub (Jun 25, 2023): I appreciate your feedback, and I agree with points 1, 3, and 4 as you mentioned. Regarding point 2, I should have attach the screenshots earlier. It would have been helpful to provide visual evidence from my side. I have carefully considered your feedback and taken into account your points, along with my own thoughts. Together, we have reached the following discussion till now. 1. According to the github ui on issues and pr view we can add the labels count. Github ui: <img width="1198" alt="image" src="https://github.com/go-gitea/gitea/assets/137179757/aa0ad04c-bc2d-44e9-b2ed-1ed956610b6b"> If you see the milestone only open milestone count are there. <img width="191" alt="image" src="https://github.com/go-gitea/gitea/assets/137179757/f99ac91c-003c-4812-99f5-d8038f76cb88"> **Github does not have archival label feature yet for labels.** For Gitea UI : Total number of labels will be good to show. Issue/Pr screen. Current screen of gitea: <img width="1203" alt="image" src="https://github.com/go-gitea/gitea/assets/137179757/8f8c99fe-d3b2-45a7-ba56-3ba632998ed2"> After added count: <img width="1200" alt="image" src="https://github.com/go-gitea/gitea/assets/137179757/93221e49-99dc-49e9-9af9-08843b0ab881"> The count is total number of labels including archived. ---------------------------------------------------------------------------------------------------------------------- In the current label screen in gitea → <img width="1084" alt="image" src="https://github.com/go-gitea/gitea/assets/137179757/ec271000-6a80-4bb0-9873-8b76e8374668"> Github UI: <img width="1193" alt="image" src="https://github.com/go-gitea/gitea/assets/137179757/220016c9-51c9-4f12-862d-e20b9d532ce6"> There is no count on label button, and total count is down. After archival labels features in gitea → <img width="1103" alt="image" src="https://github.com/go-gitea/gitea/assets/137179757/0b076a24-7d21-4e69-a2cb-452de913c117"> 1. Label title will remain same. 2. We will categories the label count into non archived label and archived label. 1. Non archived label → `<count> label` , where is count is the number of non archived labels and "label" as the text for count. 2. Archived label → `<count> archived`, where is count is the number of archived labels and "archived" as the text. For example <img width="268" alt="image" src="https://github.com/go-gitea/gitea/assets/137179757/c247643b-516a-43a4-8c92-555524c848b0"> Will be anchor tag grey in color. “2 archived” will be a separate tab in Label window in gitea as below screen shot <img width="1324" alt="image" src="https://github.com/go-gitea/gitea/assets/137179757/cebf335d-5b5b-4f0e-b56e-80034aa4369e"> Current label drop down in gitea when not selecting any issue/pr → <img width="1330" alt="image" src="https://github.com/go-gitea/gitea/assets/137179757/3c79dfde-54ad-4feb-896d-1e90eec0fea5"> When adding archive functionality when not selecting any issue → <img width="1299" alt="image" src="https://github.com/go-gitea/gitea/assets/137179757/68b96d9f-6b86-4c9d-b92b-c79458db4ed1"> When clicking on issue and then inside “Label” menu we will list the archived labels at the end. <img width="1327" alt="image" src="https://github.com/go-gitea/gitea/assets/137179757/2a42c5bc-1fb0-48a4-921f-ab8fe0b4f441"> Implementation Proposed → 1. Backend side → - Add a checkbox `archive(d)` on the `edit label` screen (and to the `PATCH` API route `/repos/{owner}/{repo}/labels/{id}`) - When editing a label and it is **newly** archived, store `ArchivedUnix timestamp(now)` inside the db - When a label is edited and no longer archived, set the archived timestamp to `0` 2 Frontend side → - Add a archive checkbox in the add label modal box. Similarly with edit modal box. New Label→ <img width="1330" alt="image" src="https://github.com/go-gitea/gitea/assets/137179757/d2745070-78d0-4983-b474-5644b0122265"> Edit Label→ <img width="1324" alt="image" src="https://github.com/go-gitea/gitea/assets/137179757/d9bca90e-2ecd-4bec-8629-a5c9f711134d"> I am open for further discussion. cc// @delvh

GiteaMirror commented

@6543 commented on GitHub (Jun 25, 2023):

I dont think we need a filter for issues based on archived labels ... rather just use as is but sort them with lower prio ...

@6543 commented on GitHub (Jun 25, 2023): I dont think we need a filter for issues based on archived labels ... rather just use as is but sort them with lower prio ...

GiteaMirror commented

2025-11-02 09:25:17 -06:00

@6543 commented on GitHub (Jun 25, 2023):

Also i would not add a lable counter as this has no helpfull information but will take space in ui. we dont have to port bad stuff from gh over to us

@6543 commented on GitHub (Jun 25, 2023): Also i would not add a lable counter as this has no helpfull information but will take space in ui. we dont have to port bad stuff from gh over to us

GiteaMirror commented

@acruzedeveloper commented on GitHub (Jun 25, 2023):

Also i would not add a lable counter as this has no helpfull information but will take space in ui. we dont have to port bad stuff from gh over to us

It was suggested by delvh. Whatever suits the best on the issue screen as UI point of view. Happy to implement. 😄
Feedback Noted. 💯

@acruzedeveloper commented on GitHub (Jun 25, 2023): > Also i would not add a lable counter as this has no helpfull information but will take space in ui. we dont have to port bad stuff from gh over to us It was suggested by delvh. Whatever suits the best on the issue screen as UI point of view. Happy to implement. 😄 Feedback Noted. 💯

GiteaMirror commented

2025-11-02 09:25:17 -06:00

@acruzedeveloper commented on GitHub (Jun 25, 2023):

I dont think we need a filter for issues based on archived labels ... rather just use as is but sort them with lower prio ...

Which screen shot you are referring, is it this screen

or something else in my feedback

@6543

@acruzedeveloper commented on GitHub (Jun 25, 2023): > I dont think we need a filter for issues based on archived labels ... rather just use as is but sort them with lower prio ... Which screen shot you are referring, is it this screen <img width="808" alt="image" src="https://github.com/go-gitea/gitea/assets/137179757/a1eba96c-23c5-46bd-abba-af16fea65cc1"> or something else in my feedback @6543

GiteaMirror commented

2025-11-02 09:25:17 -06:00

@6543 commented on GitHub (Jun 25, 2023):

Uh yes if this is a button to filter the displayed lables to select, then its an awesome feature but should be visible distinguish from the other "issue pre filters"

@6543 commented on GitHub (Jun 25, 2023): Uh yes if this is a button to filter the displayed lables to select, then its an awesome feature but should be visible distinguish from the other "issue pre filters"

GiteaMirror commented

@acruzedeveloper commented on GitHub (Jun 26, 2023):

Your understanding is correct. Let me rephrase this with more intuitive way. I am gonna make minor some changes in UI.

By default we will not show any "Archived Label" in the label filter list. Ui will be as below.

We are providing a filter []Include archive labels in search

When the filter is enabled. Archived labels will be included in label list, as per below screenshot.
When you search the label, that can be an archived or non archived, as per below screenshot.
All functionalities will remain the same.

@delvh cc// @6543

@acruzedeveloper commented on GitHub (Jun 26, 2023): Your understanding is correct. Let me rephrase this with more intuitive way. I am gonna make minor some changes in UI. 1. By default we will not show any "Archived Label" in the label filter list. Ui will be as below. <img width="1371" alt="Screenshot 2023-06-26 at 1 25 43 PM" src="https://github.com/go-gitea/gitea/assets/137179757/d42920e8-a498-47df-a514-60e8b720d3b1"> We are providing a filter `[]Include archive labels in search` <img width="265" alt="image" src="https://github.com/go-gitea/gitea/assets/137179757/dc7103c0-d69b-4332-b709-82039c856d50"> 2. When the filter is enabled. Archived labels will be included in label list, as per below screenshot. <img width="1228" alt="Screenshot 2023-06-26 at 1 32 03 PM" src="https://github.com/go-gitea/gitea/assets/137179757/f87a1fc7-2825-42a3-9740-fa6a3a4152d6"> 3. When you search the label, that can be an archived or non archived, as per below screenshot. <img width="449" alt="Screenshot 2023-06-26 at 1 51 41 PM" src="https://github.com/go-gitea/gitea/assets/137179757/182e6675-51ec-4fe3-b6ba-6b0c8547d6f7"> 4. All functionalities will remain the same. @delvh cc// @6543

GiteaMirror commented

@6543 commented on GitHub (Jun 27, 2023):

awesome ui mockup!!! - ACK :)

@6543 commented on GitHub (Jun 27, 2023): awesome ui mockup!!! - ACK :)

GiteaMirror commented

@delvh commented on GitHub (Jun 27, 2023):

New Label→

I haven't quite understood yet why we should display it on the new label screen.
Who wants to create a label and immediately archive it?
That sounds too rare to me to clutter up the UI here.
This is one of the rare instances where I think that omitting (this) functionality is better than including it.

@delvh commented on GitHub (Jun 27, 2023): > New Label→ ![popup](https://user-images.githubusercontent.com/137179757/248577308-d2745070-78d0-4983-b474-5644b0122265.png) I haven't quite understood yet why we should display it on the `new label` screen. Who wants to create a label and immediately archive it? That sounds too rare to me to clutter up the UI here. This is one of the rare instances where I think that omitting (this) functionality is better than including it.

GiteaMirror commented

@acruzedeveloper commented on GitHub (Jun 27, 2023):

Feedback Noted. I thought we are sharing the same modal for editing and new label stuff.

Who wants to create a label and immediately archive it?

Motivation was the same, If any one wants creates an archived label. He/she can edit that label to archive it.
Will remove it from New Label. 💯

@acruzedeveloper commented on GitHub (Jun 27, 2023): Feedback Noted. I thought we are sharing the same modal for editing and new label stuff. >Who wants to create a label and immediately archive it? Motivation was the same, If any one wants creates an archived label. He/she can edit that label to archive it. Will remove it from New Label. 💯

GiteaMirror commented

@puni9869 commented on GitHub (Aug 14, 2023):

Updates in designs:

Addding a info button on edit label model.

@puni9869 commented on GitHub (Aug 14, 2023): Updates in designs: Addding a info button on edit label model. <img width="663" alt="image" src="https://github.com/go-gitea/gitea/assets/80308335/746428e0-40bb-45b3-b992-85602feb371d">

GiteaMirror commented

@lunny commented on GitHub (Aug 14, 2023):

resolved by #26478

@lunny commented on GitHub (Aug 14, 2023): resolved by #26478

GiteaMirror commented

@delvh commented on GitHub (Aug 14, 2023):

Erm, no.
Only the backend structure exists yet, they are not yet handled specially.

@delvh commented on GitHub (Aug 14, 2023): Erm, no. Only the backend structure exists yet, they are not yet handled specially.

GiteaMirror commented

@puni9869 commented on GitHub (Aug 23, 2023):

We will give the entire list of labels with a hint Archived adjacent to label name.

On hovering over the Archived I will show the tooltip.

and in upcoming PR I will research and try to find the perfect UI for label screen where we can put this on screen.

These are the option I have implemented or came so far.

Open for suggestions.

@puni9869 commented on GitHub (Aug 23, 2023): We will give the entire list of labels with a hint *`Archived`* adjacent to label name. ![image](https://github.com/go-gitea/gitea/assets/80308335/bb7cbf3d-af05-44c4-8b26-56408d0b672d) On hovering over the *`Archived`* I will show the tooltip. <img width="518" alt="image" src="https://github.com/go-gitea/gitea/assets/80308335/519de666-0df4-4194-ad9d-e82d326d5526"> and in upcoming PR I will research and try to find the perfect UI for label screen where we can put this on screen. These are the option I have implemented or came so far. Open for suggestions.

GiteaMirror commented

@stuzer05 commented on GitHub (Sep 18, 2023):

Do labels actually hide currently on latest dev commit? Or just label status=archives is implemented as a flag? Because we have org-level labels, which are marked as archived, but I can see them everywhere still (on the issue list filter, at issue page in labels select).

@stuzer05 commented on GitHub (Sep 18, 2023): Do labels actually hide currently on latest dev commit? Or just label status=archives is implemented as a flag? Because we have org-level labels, which are marked as archived, but I can see them everywhere still (on the issue list filter, at issue page in labels select).

GiteaMirror commented

@delvh commented on GitHub (Sep 18, 2023):

Both:
The flag is implemented, but the labels are not really hidden yet.
The commit above your message brought the first step of "hiding" them with the rest yet to follow.

@delvh commented on GitHub (Sep 18, 2023): Both: The flag is implemented, but the labels are not really hidden yet. The commit above your message brought the first step of "hiding" them with the rest yet to follow.

GiteaMirror commented

@stuzer05 commented on GitHub (Sep 18, 2023):

Both: The flag is implemented, but the labels are not really hidden yet. The commit above your message brought the first step of "hiding" them with the rest yet to follow.

Alright, thank you

@stuzer05 commented on GitHub (Sep 18, 2023): > Both: The flag is implemented, but the labels are not really hidden yet. The commit above your message brought the first step of "hiding" them with the rest yet to follow. Alright, thank you

GiteaMirror commented