nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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.

Accepted answers

Andrew Frayling

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.

All comments

Andrew Frayling

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.

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.

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.

Edwin Stol2

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

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

Red Created, Green Resolved

Edwin Stol2

Is your resolution for these issues filled?

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?

Edwin Stol2

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

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 Stol2

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.

Jay33

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?

Ross McKenrick2

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.

Kotresha B

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

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

jira-software

jira-software-cloud

status