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

Kyle Moseley _blueridge_cx_ October 2, 2014

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

0 votes
JamieA
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
October 13, 2014

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.

0 votes
Kyle Moseley _blueridge_cx_ October 13, 2014

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
Kyle Moseley _blueridge_cx_ October 13, 2014

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.

0 votes
JamieA
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
October 12, 2014

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?

0 votes
Kyle Moseley _blueridge_cx_ October 10, 2014

@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
Kyle Moseley _blueridge_cx_ October 6, 2014

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.

0 votes
JamieA
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
October 6, 2014

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.

0 votes
Kyle Moseley _blueridge_cx_ October 3, 2014

ScriptRunner: Version: 2.1.17 JIRA: 6.2.7

0 votes
Kyle Moseley _blueridge_cx_ October 2, 2014

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

0 votes
Kyle Moseley _blueridge_cx_ October 2, 2014

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

0 votes
Kyle Moseley _blueridge_cx_ October 2, 2014

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.

Suggest an answer

Log in or Sign up to answer