[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.