How do I skip a step in my workflow when a custom field value has been set?

[Janene Hoffmann]

When custom field IT Release is set to 'Emergency Migrate' 

Within a workflow, rather than going A -> B -> C

to going A -> C

Your help is appreciated!
Janene

JIRA 6.3.7
Scriptrunner  

[Jeremy Gaudet]

Off the top of my head, you can add a post-function to the A -> B transition of type "Fast-track transition an issue" (a Script Runner transition, I believe).  I haven't used it in awhile; my use-case was transitioning to status "Open" if an issue was created by someone in the developer's role, but I'd imagine you can check the value of a custom field as the condition/trigger for the transition.

[Jeremy Gaudet]

Oh, actually... maybe I'm reading the request wrong.  All you have to do here is add a condition to the A -> B transition such that it isn't available if the custom field is set, and add a direct A -> C transition with the reverse condition (that the field be set instead of not be set).  If on A and the custom field is set, you'll see the C transition, otherwise you'll see the B transition.

[Janene Hoffmann]

When I use Post-functon / Fast track transition an issue, I get an error message:

• It seems that you have tried to perform a workflow operation (Deployment Approved) that is not valid for the current state of this issue (CM-218). The likely cause is that somebody has changed the issue recently, please look at the issue history for details.

  
  first of all, nobody else is editing the issue
  secondly, I've validated the condition of my script to be true, but yet the post function script won't execute because it throws the above error 
  
  Augh - your insight is appreciated!

[Jeremy Gaudet]

I've experienced that using the "Fast Track" method in the past, but it was sporadic, and the transition itself always did take place.  Well, at least, the original transition did; in hindsight, I don't think I noticed if it fast tracked or not.  I've been assuming that there is a race of some kind in play, but I hoped it was specific to the "Create" transition, and so didn't mention it.

If you are getting that 100% of the time, then it suggests that the transition you are attempting really isn't valid.  Could there be something preventing the B->C transition from taking place?  Where is your "fast track" in the post function list?  It would have to come after at least the original change, or else it is going to try to do A->C (and fail if invalid), then try to do B->C while already at C (if A->C was valid), or something along those lines.

[Janene Hoffmann]

I actually have the Fast track transition as the last step in the post-function list (which is after Fire a generic event) as suggested by the documentaion.

what's interesting (frustrating) is the 'pop up' Action field provides a list of workflow IDs to choose from yet the process casts an error

[Janene Hoffmann]

Yes, I'm getting this 100% of the time ---- 

[Janene Hoffmann]

post_function.PNG

[Janene Hoffmann]

my log message of course is posted to the log files

[Janene Hoffmann]

post_function_order.PNG

[Jeremy Gaudet]

The pick-list lists all transitions, including those not present in the current workflow.  Is "121" the ID of your specific transition from B->C, where B is "PENDING BUSINESS..."?

[Janene Hoffmann]

Your help is appreciated - thank you!

[Janene Hoffmann]

Jeremy, yes 121 is the transition ID going from B – > C
(the deployment was approved) 

[Jeremy Gaudet]

Is there a Condition (or Validator) on transition 121 that isn't being met?

[Janene Hoffmann]

currently I'm not using any validators nor conditions in any of the transitions in the workflow 

however, I am using post-function custom e-mails, but without conditions and those are generating just fine 

[Jeremy Gaudet]

I would try adding log entries to capture the state of the issue at the time the fast-track fires.  In particular, I'm curious as to what "issue.getStatusObject.getName()" is.  As unlikely as it seems, the only remaining idea I can think of is that a listener is firing as a result of the Generic Event, and that is changing something.  Failing that, maybe something is preventing the new status from showing up, and so it thinks you are trying to go from A->C; if so, showing the status should tell us that.

Just to confirm, the issue is staying in status B, correct?  It's not in C when you reload it?

[Janene Hoffmann]

Correct, it's staying in B status. 

Simply using 'canned' listeners.
post_function_canned_listeners.PNG

Notification scheme being used.

notificaiton_scheme.PNG 

[Jeremy Gaudet]

Weird.  Lets recap:

• The "Fast Track" post function is on transition A->B.
• As a result, when it fires, the IssueStatus should be B.
• 121 is the ID of the B->C transition ("Deployment Approved") that is in the workflow.  As in, specifically, it is on IssueStatus B.
• The condition is met and the "Fast Track" fires.
• The error makes no sense; we are in B, 121 is a valid transition out of B, but it says the transition "Deployment Approved" is not valid.

The only thing I can think of is that JIRA doesn't think we are in B; to verify, please add a log entry to the Fast Track condition:

log.error("IssueStatus: " + issue.getStatusObject().getName());

If we can't work this out, my suggestion would be to add a new A->C transition called "Skip Approval", that only shows up if the custom field is set.  Conceptually, that may make more sense than using "Submit for Approval".  The process would still be the same; set the custom field, then run the transition.  Or is the custom field on a screen that is part of the "Submit for Approval" transition?  If so, then that won't work at all; the alternative then is to use a custom listener instead of a post-function, assuming it doesn't have the same problem executing the step.  That's overkill though, so hopefully we can work this out.