[Proposal] Add third issue state "Resolved"

[delvh]

• Gitea version (or commit ref): 1.14.0

Description

When scrolling through issues (for example in a project or in a milestone), one thing becomes clear pretty soon:
You have no clear indication whether an issue has been closed because it got implemented/ fixed or whether it has been closed because it was a duplicate, not a valid issue,…
For example, for PRs this distinction exists, that they get shown like this, when they get merged:

Versus when they get closed:
.
This is not the case for issues: Simply by looking at a closed issue, you do not know whether it has been closed because it was implemented, or because it was invalid.

As far as I know, no Remote Git service so far supports issues that can be declared as "resolved" (if anyone has a better name, write a comment below), and that is a feature that in my opinion is far underrated: It allows for better housekeeping, cleaner release notes, …

Of course, issues marked as resolved should have their own icon to distinguish them from open and closed issues.
It might even be necessary to change the color of an open issue so that an issue that was resolved can be green, as that is in my opinion the most fitting color for such an issue (shouldn't be too hard to change given they are svgs...)

For backwards compatibility, it might be useful to declare the closed issue as default way to close an issue.

One final remark, "open", "closed" and "resolved" should be mutually exclusive. No issue should be able to be in more than one state at the same time, I'd say.

When to mark an issue as resolved

• the issue was mentioned with Fixes/ Closes/… #ABCD in a PR that was merged
• the issue was manually resolved (needs an extra option when closing)

[lunny]

The issue could be called Resolved but not Closed.

[a1012112796]

optional close reason for an issue:

• resolved
• invalid
• duplicate
• ...

[delvh]

While that might be possible, I don't know if we really should support that many closing reasons.
Differentiating implemented/ fixed issues from closed issues makes sense, I'd say.
But adding x possible closing mechanisms is probably not user friendly.
I mean, if you want to do it, do it, but I'm only asking for a third type to differentiate issue types better.

[silverwind]

I'd rather not have gitea become the next Jira which has such convoluted UI, so I think we should keep to basic open/close states.

[lunny]

Or we can have a issue_ref table which stored which PR fix this issue. So that we could not add a new state.

[delvh]

Yeah, a compromise for what @silverwind said could also be that only issues that really get closed by a branch declaring Fixes/ Closes/… #ABCD get closed and the user has no way to change that behavior in any other way.
This would be essentially what @lunny suggested directly above this comment.
I would also be fine with that implementation, as it does not add any complexity for the user at all.

[silverwind]

Yes something reference to how it was closed should be good. I think we could maybe have a purple list icon on issues closed by a commit, analogous to merged pull requests, thought that may contradict with the open/close state seen within the issue itself.

[lafriks]

Also would be nice to link this state when closing issue itself (like with comment Fixed in #ABCD)

[wolterhv]

Isn't this one of the use cases for labels? One of the default labels is "wontfix", another one is "invalid", for example.

[chriseaton]

Isn't this one of the use cases for labels? One of the default labels is "wontfix", another one is "invalid", for example.

This is how we use it as well, labels and comments for details- but closed is closed.

[BLumia]

For the record, GitHub now supports issue state since May 19th update, with the default close action be "Close as completed" (complete) which means "Done. closed, fixed, resolved", and an option "Close as not planned" (not-planned) for "Won't fix, can't repro, duplicate, stale":

[silverwind]

We should probably keep 2 states (open/close) state and maybe add a field like closeReason.

[BLumia]

We should probably keep 2 states (open/close) state and maybe add a field like closeReason.

GitHub also still keeps 2 states (open/close), the extra info is provided by an additional attribute names state_reason, with currently two possible value complete (the default one) and not-planned.

Personally, I would like to +1 for do the same instead of recommend user to fiddle with tags, since:

• Reason of closing an issue could be very, but the state_reason represent the two main type/catalog of close reason: positive and negative, or say, valid and invalid. If detailed reason needs to be provided, then tag could be useful.
• Currently issue tags cannot be modular/grouped, which results in a bunch of tags to select even if we only want to add a single dimension of data.
  • There is actually a feature request for this: [Feature Request] Modular issue label sets #18583
  • Although GitHub's issue tags also aren't modular, GitHub does have a pretty useful Project (the one currently in beta, not the old Kanban-only style one) panel allow adding extra field that's modular. Also see this.

[KlavsKlavsen]

I think this proposal of mine, would solve this need - and allow for any level of "states" anyone wants - without adding clutter to gitea: #26704
WDYT ?

[KlavsKlavsen]

We also just added #26661 - which could be extended to have a "label dropdown" filter too (to make it easier to f.ex. find all issues with specific label :)

[silverwind]

See #25362 and linked issues for some recent activity on this topic.

[KlavsKlavsen]

Thing is we have more states we actually use - and we NEED to have an overview over which state an issue is in - so we "can do something"..
we have f.ex. a "Waiting on external" - where we assign the waiting label.. But we also have a kanban waiting column - so its clear from overview that its NOT progressing in kanban view.
Instead of having to manually assign (and remove) labels everytime we move the issue across the kanban board (and people forget to do it !) - it would be REALLY helpful for us to have this feature that I proposed:
#26704

I hope I could get an indication if this PR would be accepted (with code/design changes ofcourse - per input from you) - before I assign one of my team to work on it.

[KOT4N]

bamp