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; } } }

workflow transition: post function conditions

Prasad

a) When Resolved status is chosen by the Developer in the Bug screen, system should mandate an update in the “Resolution” field as one out of Fixed/Not Fixed as values (system shouldn’t display any other fields other than these 2 in the drop down)

Similarly

a) When Closed status is chosen by the Tester in the Bug screen, system should mandate an update in the “Resolution” field as one out of Fix Verified/Deferred/Not Reproducible/Not a Bug as values (system shouldn’t display any other values other than these in the drop down)

Is this feasible to accomplish? If so please assist.

Accepted answers

Nic Brough -Adaptavist-

Ok. First, you do not just "choose a status" - you choose to run a transition that changes the status. It doesn't matter what screen you are currently in, and status is not a field. The transition can handle all the conditions, post functions and validators (it's very important to understand that these are very different things), and it can go through a screen to prompt the user for more information.

So, for your first point, you want a transition that

Goes from <unknown/global> to Resolved
Goes through a screen with just the resolution field on it (remember, the status is "chosen" by choosing the transition, it is not a field).
You can use "workflow properties" to reduce the list of available resolutions by removing the options you don't want the user to enter (note that just having the resolution on-screen will make the user enter something)

For your second point, you need a second transition, very similar, but with a different end point, and different workflow properties.

Oops. I forgot, I should have pointed you to https://confluence.atlassian.com/display/JIRA/Workflow+properties for the include/exclude resolutions stuff

All comments

Nic Brough -Adaptavist-

So, for your first point, you want a transition that

Goes from <unknown/global> to Resolved
Goes through a screen with just the resolution field on it (remember, the status is "chosen" by choosing the transition, it is not a field).
You can use "workflow properties" to reduce the list of available resolutions by removing the options you don't want the user to enter (note that just having the resolution on-screen will make the user enter something)

For your second point, you need a second transition, very similar, but with a different end point, and different workflow properties.

Oops. I forgot, I should have pointed you to https://confluence.atlassian.com/display/JIRA/Workflow+properties for the include/exclude resolutions stuff

Prasad

Hi,

i went through your response. Still my question remains unanswered. I do agree that the Validations, Post functions are different altogether. My question is:

1) whether JIRA can mandate the user to update the "Resolution" field when the issue is transitioning from one status to another status. example: Developer must update Resolution field as "fixed" and move the workflow from "Work in Progress" to "Resolved". Is there any Java coding required to accomplish this. I tried exploring the "Post function" parameters, where in the JIRA administrator can edit the 5th line item (Fire a Generic Event event that can be processed by the listeners) and customize. But the available options in there are not very much useful for me. Besides, i tried "Add post function" as well. what i'm expecting is, the drop down values for the "Resolution" field should vary from "Resolved" Status to "Closed" Status. In case we need to discuss over a call, we can do it.

Hope my question is clear???

Nic Brough -Adaptavist-

Ok, that is a set of slightly different questions. I'll try to separate it out: >whether JIRA can mandate the user to update the "Resolution" field when the issue is transitioning from one status to another status. There are two things here. First, your original question was really about limiting the resolutions available to the user when they use the transition. Hopefully I've covered that. Secondly, you've added a requirement to force a *change* on the resolution when the user goes through the transition. I think you've misunderstood my point about putting the field on the screen. When you put the resolution on the screen, it already forces the user to change it from <null> to <something> However, that only applies for cases where the resolution was empty before. If your transition is genuinely "resolve issue", taking it from "unresolved" to "resolved", then that works. But it now sounds like you already have a resolution set, so you're *not* resolving the issue here, you're editing the resolution. To force a change of resolution here, you will need an extra validator to say "fail validation if user has not selected a new resolution". But seriously, if this transition really is a "resolve issue" transition, you do NOT need to do anything - you should have an empty resolution to start with, and just putting the resolution on-screen will force it to be set. >I tried exploring the "Post function" parameters You are now getting very confused. A post function is for "doing something after an issue has been changed". It's too late to do validation, you've committed the change to the issue. >hat i'm expecting is, the drop down values for the "Resolution" field should vary from "Resolved" Status to "Closed" Status That us where my original answer about using workflow properties applies. You want to change the available list of resolutions according to which transition you are doing.

Prasad

thanks Nic, this really answered my question. by the way, "fail validation if user has not selected a new resolution" validation is not seen in my JIRA version 6.2. should i need to go for the higher version or any workaround?

Welcome!

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

Quick Links

Find more posts tagged with

jira

jira-administration