I've transitioned to the new status, see the new transition options, but I'm still in the old status?

I've transitioned to a new status. My available transitions reflect that I'm in that new status. But I see the old status. And issue.getStatusObject().getName() returns the old status. What could be causing this? I am using scripts to transition, including fast tracks and other scripts. A refresh will not solve the problem, this thing is stuck. @Jamie Echlin [Adaptavist] and @Henning Tietgens, this is the follow up to my last post.

 

currentstatus.PNG

 

When it comes to the post functions, upon arriving in Date Change in Review status, there's approve and deny, both run this script which loops back around to Date Change in Review:

import com.atlassian.crowd.embedded.api.User
import com.atlassian.crowd.model.user.User
import com.atlassian.jira.ComponentManager
import com.atlassian.jira.component.ComponentAccessor
import com.atlassian.jira.issue.Issue
import com.atlassian.jira.util.ImportUtils
import com.onresolve.jira.groovy.canned.utils.WorkflowUtils
import com.opensymphony.workflow.WorkflowContext
import com.atlassian.jira.issue.IssueManager
import com.atlassian.jira.user.ApplicationUser
import com.atlassian.jira.workflow.WorkflowUtil
Thread.sleep(1000)
def IssueManager issueManager = ComponentManager.getInstance().getIssueManager()
// issue declaration below is for testing
// def Issue issue = issueManager.getIssueObject("SAND-4")
def componentManager = ComponentManager.getInstance()
def changeHistoryManager = componentManager.getChangeHistoryManager()
def PrevStat = changeHistoryManager.getChangeItemsForField(issue, "status").getAt(changeHistoryManager.getChangeItemsForField(issue, "status").size() - 2).getFromString()
def User user = WorkflowUtil.getCallerUser()
Thread.sleep(1000)
if (issue.getStatusObject().getName() == "Date Change in Review") {
x = "failed somehow"
// there's an opportunity here to have issueWorkflowManager.getAvailableActions(issue) parse those results then auto find the transition...
if (PrevStat == "Open") {
	WorkflowUtils.actionIssue("", issue, 821, user)
		x = "a"
}
if (PrevStat == "Reopened") {
	WorkflowUtils.actionIssue("", issue, 831, user)
	x = "b"
}
if (PrevStat == "Awaiting Response") {
	WorkflowUtils.actionIssue("", issue, 801, user)
	x = "c"
}
if (PrevStat == "Work Halted") {
	WorkflowUtils.actionIssue("", issue, 791, user)
	x = "d"
}
if (PrevStat == "In Progress") {
	WorkflowUtils.actionIssue("", issue, 811, user)
	x = "e"
}
if (PrevStat == "Closed") {
	x = "f"
}
if (PrevStat == "Date Change in Review") {
	x = "g"
}
Thread.sleep(1000)
def indexManager = ComponentManager.getInstance().getIndexManager()
boolean wasIndexing = ImportUtils.isIndexIssues();
// reload issue
issue = ComponentManager.getInstance().getIssueManager().getIssueObject(issue.id)
indexManager.reIndex(issue);
ImportUtils.setIndexIssues(wasIndexing);
} else {
x = "no, we're not in date change in review"
}
Thread.sleep(1000)
return x

11 answers

And here's an update: Upon transition again, my transition history now shows the source status is Date Change in Review and then the target is my new status.

Also, running this script from the console, (so not performing the loop Accept/Deny transition) works perfectly.

I tried WorkflowTransitionUtil's transition in place of the WorkflowUtils one...same result.

ScriptRunner: Version: 2.1.17 JIRA: 6.2.7

0 vote

I see this when an issue is fast-tracked twice within the same transition, eg Start Progress automatically resolves, then Resolve automatically closes. I've done some work on this which fixes the inconsistency, but I cannot avoid that if there are two fast-tracks the user will need to refresh.

Do you think that it could be resolved by performing transition #1, landing in the status, then programmatically forcing a browser refresh and programmatically kicking off transition #2? We're trying to find a way to save this post function setup/script usage because it's worked fine in the past and we're out of ideas.

@Jamie Echlin [Adaptavist], so I think I've found the very root of our problem. We have screens on each transition containing the fast tracks. Does that sound like something that could 'break' certain fast track transitions?

0 vote

No not really. Why do you think this is the root of the problem, have you tested it without the screens and it works? Do you want a snapshot version that contains some improvements in logging when a failure occurs to test, assuming you can replicate this on a staging server?

I successfully ran through my various transitions after removing the screens. However, I cannot replicate the results now. I get the same results from the original workflow and the original workflow minus screens. So I guess I'm back to where we began: server usage is definitely a factor and almost always the first fast track will fail. The worse server load is, the more likely the following fast tracks will fail. A snap version would be great.

Did some more tests... When I take my fast tracks down to 1 single conditioned fast track, it works most of the time. On the other hand, when I leave it at 5 different fast tracks, the first with no condition (true) and the rest with their regular conditions, the first one is not automatically getting kicked off. To me, that means it is getting 'skipped'. If it's true it should always fire its transition. I also tried testing the statuses via groovy and had the same result. This is so weird. {code} import com.atlassian.jira.issue.Issue import com.atlassian.jira.issue.IssueManager import com.atlassian.jira.ComponentManager def componentManager = ComponentManager.getInstance() def IssueManager issueManager = ComponentManager.getInstance().getIssueManager() def changeHistoryManager = componentManager.getChangeHistoryManager() def i = 1 def PrevStat = changeHistoryManager.getChangeItemsForField(issue, "status").getAt(changeHistoryManager.getChangeItemsForField(issue, "status").size() - i).getFromString() while (PrevStat == "Date Change in Review") { PrevStat = changeHistoryManager.getChangeItemsForField(issue, "status").getAt(changeHistoryManager.getChangeItemsForField(issue, "status").size() - i).getFromString() i++ } if (PrevStat=='Reopened') { x = true } else { x = false } return x {code}

0 vote

You can get the snapshot from https://jamieechlin.atlassian.net/wiki/download/attachments/1212418/groovyrunner-3.0.7-SNAPSHOT.jar?api=v2 . The main difference IIRC is that it should report accurately why it failed to transition, perhaps due to a condition failure.

Suggest an answer

Log in or Sign up to answer
How to earn badges on the Atlassian Community

How to earn badges on the Atlassian Community

Badges are a great way to show off community activity, whether you’re a newbie or a Champion.

Learn more
Community showcase
Published Sunday in Agility

You asked for it, so we delivered: images on issues have arrived

A picture tells a thousand words. And agility boards have just released their latest feature: cover images on issues – so now your board can tell a story at first glance. Upload attachmen...

411 views 3 11
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