Difference between Issue resolved and Issue closed events in notification scheme

[Dmitry Kuzmin]

In JIRA notifications schemes there are "Issue resolved" and "Issue closed" events.

 According to this https://confluence.atlassian.com/jira064/creating-a-notification-scheme-720412453.html

Issue Resolved:	An issue has been resolved (usually after being worked on and fixed).
Issue Closed:	An issue has been closed. (Note that an issue may be closed without being resolved; see Workflow).

In particular i'm interested in that an issue may be closed without being resolved.

But according to https://confluence.atlassian.com/jira064/configuring-workflow-720412524.html

• An issue is Open if its Resolution field has not been set.
• An issue is Closed if its Resolution field has a value (e.g. Fixed, Cannot Reproduce).

The question is when the "issue closed" event is fired? And how does it connects with obliterated representation of an issue. That is, JIRA-1 means an issue being resolved or closed? And what's the meaning of "closed" that way?

[Nic Brough -Adaptavist- · Accepted solution]

JIRA has two "fields" (one of them isn't a field, but for this, it might as well be).

The Status tells you where the issue is in the workflow.  It does not tell you anything about the issue's resolution, even though it might say "resolved", "closed", "done", "fed to penguin", it's just an indicator of where it is.

Resolution is the more important one - if it is empty, JIRA sees the issue as "open" (and displays "unresolved" on screen, even though it's empty), whatever the status is.  It considers it "done" if it has any data value at all.

Events are not really related to that.  Some are fired by "actions" (edit, comment, move, etc), but the two you're looking at are part of the workflow.  In JIRA version 1, there was only one workflow, and it had status including Resolved and Closed.  The workflow fired "issue resolved" when a user went through a transition into "resolved" and it fired "issue closed" when they went through transitions to "closed".

In version 2 and above, workflows became flexible.  Not only could we move the transitions around and change the list of status in them, we can also change the events fired, and define our own.  The two you're looking at now don't necessarily have to mean what they say any more - you could easily have a transition from "purple" to "orange" that fires "issue resolved" and equally, have a transition from "open" to "resolved" that fires "issue re-opened".  Of course, there's little sense in doing it, but you could.

Think of the list of events you have as being a default set of events that are configured well by default (by the built in workflow and by the ones JIRA can create when you use project templates).  The events do NOT have anything to do with the resolution directly though.

A good guideline is to always think about where you want to set and clear your resolution when you build a workflow, and then, as a different task, what events you want that workflow to fire on a transition.

[Kashif Pervaiz]

I believe the simple answer is:

• If Status is of the "Done" category (the green box in the workflow), the issue closed event is fired. 
• If resolution is set that will fire issue resolved event.

[Corentin Méhat]

Hello,

in order to identify the event fired, you need to check in your worklow settings which event is fired on the transition. It should be the last "post-function" launched. 

The strikethrough means that the issue has been resolved.

For the closed vs. resolved, it's a question of interpretation. I suggest you to read : https://answers.atlassian.com/questions/35714

[Venkatesh Pattamatta]

I am a Tester and I wonder why isn't anyone talking about a status of Compliance/QA! Maybe all are developers haha! My idea of the workflow is:

Status......................Resolution

Open............................Un Resolved

In Progress...................Un Resolved

QA.................................Fixed

Resolved/Done..............Closed

From QA it can go another way Re opened (Status) with unresolved (resolution)

Correct me if I am wrong

[David Ludwig]

This is what I am looking for, and I am a developer.

[Nic Brough -Adaptavist-]

That's just one workflow.  It's right, as it maps resolution in a useful way, but I'd question the "QA = fixed" because it means the issues are resolved when they are in QA, and that is wrong for a lot of people.

[Venkatesh Pattamatta]

Its not Resolved when testing isnt done yet, its just Fixed which means its fixed by Developer. But the Status shouldn't be set to Resolved, it should be set to Compliance/QA.

[Nic Brough -Adaptavist-]

Nope.  If you put a value in the resolution, then the issue is resolved/closed/ended/done/whatever.  End of story.

In your workflow, if you don't want "in QA" to mean "resolved", you need to not map a resolution.

Please have a read of the answer I gave two years ago

[Dmitry Kuzmin]

 Nic Brough [Adaptavist], Corentin Mehat, thank you for your answers!

With you help i finaly got it clear. The last thing that bothered me was that i couldn't find "Issue closed" event in list of options of "fire event" postfunction. The reason is the name of event is translated by JIRA (it is contained in the list, but is called differently) , though english is set in my preferences.

[Corentin Méhat]

Your instance might have been initially installed with a base language that is not English, or english is your profile preference but not the default JIRA language. In either case I  suggest that you have a look at the workflow transition postfunction and I think you should find the proper event over-there.