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

[Kyle Moseley _blueridge_cx_]

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

[JamieA]

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.

[Kyle Moseley _blueridge_cx_]

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}

[Kyle Moseley _blueridge_cx_]

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.

[JamieA]

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?

[Kyle Moseley _blueridge_cx_]

@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?

[Kyle Moseley _blueridge_cx_]

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.

[JamieA]

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.

[Kyle Moseley _blueridge_cx_]

ScriptRunner: Version: 2.1.17 JIRA: 6.2.7

[Kyle Moseley _blueridge_cx_]

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

[Kyle Moseley _blueridge_cx_]

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

[Kyle Moseley _blueridge_cx_]

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.