Fast-track transition an issue doesn't bring up the transition screen

[Poojaa Sudhakaran]

Hello there,

I'm using Scriptrunner "Fast-track transition an issue" listener to automatically transition an issue from from "Backlog" to "In Sprinting" status if the sprint field is updated. This functionality is working fine but the problem I'm facing is, I have a transition screen associated with the "Backlog" to "In Sprinting" transition.

During manual change from one status to another another, the transition screen appears but during the auto-transition using "Fast-track transition an issue", the transition screen doesn't show up and the issue is moved to the next state.

Is there anyway where I can move the issue to next status upon a field update with the transition screen popping up?

Thanks in advance!

Poojaa

[Nic Brough -Adaptavist-]

The point of a fast-track is that it happens without human intervention.  It therefore ignores screens.

[Poojaa Sudhakaran]

I agree, But I tried performing status change using a custom listener as well. Even this ignores the transition screen. PFB - A Custom Listener Code that fires on Issue Update event.

Do I need to add something in the existing code to bring up the transition screen or do I need to follow any other approach?

import com.atlassian.jira.component.ComponentAccessor
import com.opensymphony.workflow.WorkflowContext;
import com.atlassian.jira.workflow.WorkflowTransitionUtil;
import com.atlassian.jira.workflow.WorkflowTransitionUtilImpl;
import com.atlassian.jira.util.JiraUtils;
import com.atlassian.jira.issue.MutableIssue;

log.warn "Issue: ${event.issue}"

if (event.issue.issueType.getName() != "Story")
return

if (!(event.issue.getStatus().getSimpleStatus().getName() in ['Ready']))
return

def change = event?.getChangeLog()?.getRelated("ChildChangeItem")?.find {it.field == "Sprint"}

MutableIssue issue = (MutableIssue) event.issue
def sprint = ComponentAccessor.customFieldManager.getCustomFieldObjectByName("Sprint")
def sprintValue = issue.getCustomFieldValue(sprint)
log.warn "${sprintValue}"

if (change && sprintValue != null) {
WorkflowTransitionUtil workflowTransitionUtil = (WorkflowTransitionUtil) JiraUtils.loadComponent(WorkflowTransitionUtilImpl.class);
workflowTransitionUtil.setIssue(issue);
workflowTransitionUtil.setAction(141);
log.warn "Screen: ${workflowTransitionUtil.hasScreen()}"
workflowTransitionUtil.validate();
workflowTransitionUtil.progress();
}

[Nic Brough -Adaptavist-]

Listeners happen after transitions, they're not for interaction.

If you want to see a transition screen, you have to get a person to go through the transition.

I am really quite confused on what you are trying to do here.  You're trying to automate something, but want to have a human do part of it.  If a human needs to see the transition screen, why are you not getting them to do the transition?  What is the benefit of automating something that still needs a human to look at it?

[Poojaa Sudhakaran]

Hello Nic,

Thanks for the follow up. I agree listeners happen after transition. But in my use case I'm not using listener to respond to a transition.

My Listener's trigger event is a field update. Once a field has been updated, issue should move to the next phase.

Once "Sprint" field is updated, the issue should move to the sprinting phase of the workflow. Here, we are using transition screen to let the user know few parameters that are required in the sprinting phase.

The need for automation here is the two step process. Sometime user may forget to update the phase of the issue even though the field has been updated. We are trying to avoid this scenario.

Before automation: 1. user has to update sprint, 2. manually move it to sprinting phase and 3. verify the transition screen parameter.

After automation: 1. User has to update sprint and 2. verify the transition screen.

Thanks,

Poojaa

[Nic Brough -Adaptavist-]

No, this cannot work, it's a logical impossibility, and even if you could do it, an absolute nightmare for your users.

Stop trying to do things this way, it's terrible.  If "sometime user may forget to update the phase of the issue after changing the field", then fix the process.  Stop getting them to change the field, get them to change the phase and validate that the data in the field is right.