Different Resolution options according to issue type

[GilK]

Hi,

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?

[Joe Pitt · Accepted solution]

Check out restricting resolutions visible at transition at http://confluence.atlassian.com/display/JIRA/Workflow+Properties 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.

[GilK]

Thanks Joe,

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

Thanks,

[Jobin Kuruvilla [Adaptavist]]

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

[GilK]

Do you use

jira.field.resolution.exclude or

jira.field.resolution.include for the resolution field

?

Why?

Thanks so much !

[Nic Brough -Adaptavist-]

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

[GilK]

Thanks,

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

Thanks,

[Nic Brough -Adaptavist-]

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

[GilK]

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

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

Thanks,

[Nic Brough -Adaptavist-]

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")?

[Ben Weisman]

Hi @Nic Brough -Adaptavist- , I'm trying to add multiple resolution options but it is only showing the first one. Is comma not the correct seperator?

[Ben Weisman]

Nevermind @Nic , i had a space after the comma!

[Nic Brough -Adaptavist-]

That's exactly what bites me on the bum too when I'm trying to do clever things with properties!  Well spotted!

[Colin Goudie]

This isn't supported in JIRA

You can vote here - https://jira.atlassian.com/browse/JRA-3821

[Jeremy Gaudet]

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.

[Nic Brough -Adaptavist-]

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.

[GilK]

Thanks,

So how you handle the different issue types resolution?

What would be the best practice for it?

Thanks,

[Nic Brough -Adaptavist-]

I use the workaround I mentioned.

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

[Vishnukumar Vasudevan]

Nic

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.

[GilK]

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?

Thanks,

[Nic Brough -Adaptavist-]

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.

[GilK]

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

I didn't get it.

Thanks,

[Nic Brough -Adaptavist-]

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 http://confluence.atlassian.com/display/JIRA/Configuring+a+Custom+Field 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.

[GilK]

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

Thank you so much!

[Nic Brough -Adaptavist-]

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.

[M. P.]

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 https://confluence.atlassian.com/display/JIRA/Workflow+Properties 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.