What is the difference between closed and resolved status in GreenHopper?

[David Parks]

What is the difference between Closed and Resolved status in GreenHopper? Why have two? They sound the same to me.

[Andrew Frayling · Accepted solution]

Hi David, they're subject to your own definitions, but generally "resolved" means a developer has fixed the reported problem and "closed" means that a resolved issue has been confirmed as fixed by the reporter or a QA team. It really depends on your workflow and whether you want a verification step when a developer has said they've fixed something. Hope that makes sense? Andrew.

[Peter Shiner]

A slightly different use would be that Resolved issues are fully resolved, having been through product quality assurance. But Closed issues have been through some sort of retrospective. This would tend to highlight the delayed nature of the review, distinctly separate from the normal product realization cycle. If you have strong processes for process improvement then this approach may provide some documentation for the more formal approach. Of course going this route you are not going to want to review every tiny defect so a new workflow for items never going through this process or making it optional on other workflows is very likely.

I think this shows that your only limitation is your own imagination.

[Alexander Küken]

As addition to the previous answers:

We use these two as Andrew and Julien described. While an issue in status Resolved is still editable, Closed is a final state. So closed tickets are not editable any more. I think this is also the default behaviour of the standrd workflow.

[Julien Hoarau]

It depends on your workflow but in my company we use theses like that:

• Developer A fix an issue, he changes the status to Resolved.
• Tester A (or the one who opened the bug) checks the fix, if it is ok he changes the status to Closed.

[Steffen Behn]

We use the Work-Mode and drag it to Resolved (Test Stage), QA then drags it to Ready to deploy, the developer deploys the feature to Live and drags the ticket to Test Live where QA then drags it to Closed.

Does that answer your question?

[Kotresha B]

 My tickets are not moving to resolved state after closing, can anyone help me.

[Ross McKenrick]

I also have a defect workflow where Resolved is an intermediate state (for reasons stated by @Andrew Frayling).  However, this is problematic in JIRA, since JIRA considers an issue resolved (and shows the issue key with the strike-through font) when the Resolution field is filled in, not when the issue is in Resolved state–and in all my workflows, I have JIRA fill the Resolution field when an issue enters its final state (which is Done for Stories and Closed for Defects).

When the Resolution field is not filled in, JIRA shows the Resolution as Unresolved. This leads to the situation that I have where defects are in Resolved state but the Resolution says Unresolved.

See https://confluence.atlassian.com/display/DOCSPRINT/Resolved,+Resolution+and+Resolution+Date for a little more information on this.

At this point, I see three choices. Make a special case for defects and set the Resolution field when they are transitioned to Resolved state. Stop populating the Resolution field. Or find a new name for the intermediate step in my Defect workflow.

Another gotcha to beware of is that JIRA Agile (formerly Greenhopper) counts an issue as Done not when it is transitioned to Done state (or any final state in a workflow), but when it is transitioned to a state which is mapped to the right-most column of the Agile board.

[Jay]

even with all of these answers, which I appreciate, I still think the resoltion field is unnecessary. My opinion. Everything you are saying should be handled with the workflow (status). I don't see the need for a resolution field. It's not that it can't be used, it's just superflous.

Why not just transisiton to QA when developer has resolved and if QA is passed, then Closed else send back to development?

[Edwin Stol]

That doesn't matter; Resolved nor Closed trigger what you want; that's based on the resolution.
Try a bulk change to add a resolution for the closed or resolved issues, or use the Jamie Echlin's Script Runner for this.

Reindex afterwards to be sure, and you'll see that it's changed.
Other way is to incorporate the 'Resolve Issue' screen in one of the status transitions.

[Steffen Behn]

No, but the status is mapped to the (Test Stage) Column and it also uses the correct icon. I figured that shows me if I use the preconfigured Jira statuses or any of my own.

[Edwin Stol]

No, not really.
It depends on what your transition(s) trigger; do you get the 'Resolve issue screen' on a certain stage?

[Edwin Stol]

Is your resolution for these issues filled?

[Steffen Behn]

This all makes sense, but why do I then have an overview on the project page saying that I have not resolved any issues. Most of those issues are actually already Closed.

Open -> In progress -> Resolved -> Closed

Anybody cares to elaborate?

Regards,
Steffen

[Edwin Stol]

We use Resolved for issues that are built/realised and 'Closed' for issues that are not built/realised (the Won't Fix, Duplicates, etc.