It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Different Resolution options according to issue type


I have few issue types that are splitted into 3 families (different workflows):

defects: Bug, Sub-Bug, Fire

tickets: Task, Story, Epic

releases: Release to QA, Release to Integration

All of the should have a 'Resolution' field, but each one of them should have different resolutions

defects: Fixed, Won't Fixed, Invalid, etc.

tickets: Done, Not Done, Cancelled, On Hold

releases: On Hold, Pass, Failed

How do I achieve that with JIRA?

4 answers

1 accepted

9 votes
Answer accepted
Joseph Pitt Community Leader Jan 22, 2012

Check out restricting resolutions visible at transition at I suggest using the include option. If you use the exclude the transition has to be updated whenever you decide to add another resolution value. This doesn't limit the resolutions visible in the issue search however.

Thanks Joe,

How did you use it to achieve different resolutions for different issue types?


by having different workflows for different issuetypes and restricting the resolutions as apprpriate on each of them ;)

Do you use

jira.field.resolution.exclude or

jira.field.resolution.include for the resolution field



Thanks so much !

Joe specifically advised the use of "include". I agree with him.


What are the disadvatages (what do I lose) when using the include property?


Arg. Please READ Joe's original answer, it's in there.

No, I'm talking about the jira.field.resolution at all.

What do I lose when I use jira.field.resolution.include/exclude?


I really do not understand. The disadvantages of using include/exclude are in Joe's answer. I'm not going to copy and paste it.

If you mean something different, then what do you actually mean by "jira.field.resolution" (as distinct from the system field called "resolution")?

This isn't supported in JIRA

You can vote here -

0 votes

Resolutions are global, so you can't really.

There is a workaround - you can have variable resolution lists, but it's a pigging nightmare to configure. The short story is that you can have different workflows for each issue type, and it is possible to set up workflows so that you can limit the resolutions at that level, by using workflow properties. But it really is counter-intuitive and ugly.


So how you handle the different issue types resolution?

What would be the best practice for it?


I use the workaround I mentioned.

I desperately avoid it whenever I can - best practice is "educate the users not to ask"


Small doubt.

I it was a custom field, is there a way we can achieve this ?

I use JIRA 4.4.1

Thanks for your time

Regards, Vishnu.

So you have few custom resolution fields? What do you do with the original resolution field, hide it?

How many resolutions fields do you have?


Argh. That is a totally different question, why didn't you tell us that to begin with?

No, I avoid having separate resolution fields, it makes things too complex for users.

Custom fields have contexts. You can define different contexts for each field by project and/or issue type. Each context can have a different list of values. That solves your problem.

It creates another one though - the system resolution field has extra functionality - specifically what Jira tells you is "unresolved" and "resolved". If you don't use system resolution, you throw all of that functionality away.

So would you elaborate on how you achieve different resolutions for different issue types?

I didn't get it.


For the system field resolution, use workflow properties (see Joe's answer). The documentation he has linked to explains it very well.

For a custom field resolution, see and look for the section on "context"

I can't explain either of these better than the documentation - read that and ask specific questions based on your reading.

Do you use them both? You use both the system field resolution and a custom field resoultion?

Thank you so much!

It depends on the client and what is most appropriate for them and the way they want to use their Jira installation.

I advise against the use of a custom field, because, as I said before, you lose all the reporting Jira does internally (there are workarounds there too, but they're also ugly), and it's a pain to maintain. It's not as painful to look after as having to fiddle with the workflows and use the include/exclude trick, but it really does depend on the requirements of the user.

Gerenal Question: where I can find ids for my system resolution, or is it per default if I have 7 resolution, just numbering ids from 1 till 7 ? what if I deleted and added system resoultions, does it change ids? Can somebody explain how jira.field.resolution.exclude/jira.field.resolution.include option works? It's now clear through description. I tried follwing: Added 7 Resolutions (system resolution: 5 should be displayed for all issue type, rest 2 only for specific workflow ) Added properties to transition via jira.field.resolution.exclude = 1, 2, 3, 4, 5 => didn't work (only resolution with id 1 was disabled, rest was still there). Even if comment above says that it is complicated, we will have to use exclude, as we have resoultions that shouldn't be displayed for some issue types jira.field.resolution.exclude.1 = 1 -> didn't work at all Question: how to disable five resolutions ? If I'm onest I don't understand even the benefit of jira.field.resolution.include . Because if I will add resolution under Administration>Issue Attributes>Resolution it shows for all issue types. If I use jira.field.resolution.include by adding it to workflow transition, it still doesn't help. What I'm doing wrong? How to disable some resolution through workflow properties? Link to description doesn't help. There is no detailed description, only that it "should work" through this properties.

I came up with a way to do this without having to use multiple workflows.  Instead, I created multiple transitions, one per set of resolution options.  So, for example, I have "Close Bug" and "Close Issue", where "Close Bug" only allows "Fixed, Not a Bug, Duplicate, etc", and "Close Issue" allows "Completed, Abandoned, Duplicate".

To make it work such that only one "Close" transition is available per type, I added conditions based on the value of field "IssueType"; for example, "Close Issue" has an OR condition on "Story", "Task", "Sub-task", and probably 5 others, while "Close Bug" is just "Bug".

Because some of the buttons couldn't be described easily, I set the properties of each transition (jira.i18n.title and jira.i18n.submit) such that they all show up in the UI as "Close Issue", giving the illusion that they are all the same transition.

It's obviously not fully ideal; a scheme to manage this would be best as then you don't have to, say, copy validation scripts between workflows, but it's much better than having different workflows, as that makes it harder to change issue type on the fly, and seriously complicates making changes to the workflow elsewhere.

Suggest an answer

Log in or Sign up to answer
This widget could not be displayed.
This widget could not be displayed.
Community showcase
Published Apr 09, 2019 in Portfolio for Jira

Portfolio for Jira 3.0 is here!

The wait is over... Portfolio for Jira Server and Data Center 3.0 is now officially here! Platform releases offer Atlassian an opportunity to shift our strategy, make bold predictions about t...

1,401 views 14 26
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you