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 votes

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 votes

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 votes

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 Join to answer
Community showcase
Sarah Schuster
Posted Jan 29, 2018 in Jira

What are common themes you've seen across successful & failed Jira Software implementations?

Hey everyone! My name is Sarah Schuster, and I'm a Customer Success Manager in Atlassian specializing in Jira Software Cloud. Over the next few weeks I will be posting discussion topics (8 total) to ...

2,965 views 12 18
Join discussion

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
Atlassian Team Tour

Join us on the Team Tour

We're bringing product updates and pro tips on teamwork to ten cities around the world.

Save your spot