Problem to transition issue via IssueService

[Gal Zemah]

I'm trying to transition Issue from a post function of transition from some status to itself.
I'm facing either:
If the code is placed first, the value of the custom field that is filled in the last screen is not available (needed for my logic, should transition only for specific value).
And if the code is placed after the first, the status is not really changed (in the Activity, Transitions and History it looks like the status is changed but in fact not changed).

What am I missing? 
How should I transition Issues from a post function in Jira 9.x?

The code:

import com.atlassian.jira.bc.issue.IssueService

import com.atlassian.jira.bc.issue.IssueService

import com.atlassian.jira.bc.issue.IssueService

import com.atlassian.jira.component.ComponentAccessor

import com.atlassian.jira.issue.Issue

import com.atlassian.jira.user.ApplicationUser

IssueService issueService = ComponentAccessor.getIssueService()

ApplicationUser user = ComponentAccessor.getJiraAuthenticationContext().getLoggedInUser()

Integer actionId = 31

if (someCustomField == "X"){

    IssueService.TransitionValidationResult result = issueService.validateTransition(user, issue.getId(), actionId, issueService.newIssueInputParameters())

    if (result.isValid()){

        IssueService.IssueResult issueResult = issueService.transition(user, result)

    }else{

        log.error(result.getErrorCollection().getErrors())

    }

}

[Gal Zemah · Accepted solution]

Actually I found that need to add the following in order to make it work:

IssueService.IssueResult issueResult = issueService.transition(loggedInUser, result)
//store the status of the last transition
issue.setStatusObject(issueResult.getIssue().getStatus());

 
And, it works fine now!
@Nic Brough -Adaptavist- 

[Nic Brough -Adaptavist-]

Welcome to the Atlassian Community!

>How should I transition Issues from a post function in Jira 9.x?

By doing it somewhere else.  Post-functions run as part of a transition - the transition is not complete when they execute.  Best case is that you end up with an issue that doesn't know whether it is in the end-status of the original transition or the end-status of your post-function, with trashed data.  Worst case is that it recurses and takes out your server (only damages the issue that caused it, but you can take your system down with this).

There are tricks, there is code that can subvert the target of a transition (but it won't fit in a standard script, it's thousands of lines in the apps that do "fast track transition" type stuff)

We should take a small step back and look at what exactly you are trying to achieve.  Forget the transitions (and the other tech options), can you tell us what the use case is?

[Gal Zemah]

@Nic Brough -Adaptavist- 

Actually, depending on the custom field value I want to transition an issue to the appropriate status (Approve/Reject mechanism, not always transition to the same status). That’s why it should be a post function of transition of status to itself.

In fact, I had code that worked well in Jira 7.x via the workflowTransitionUtil, but in Jira 9.x the workflowTransitionUtilis deprecated, therefore I’m trying to do the same via issueService.

[Nic Brough -Adaptavist-]

You really should not be trying to do this in a post function.  One of the reasons workflowTransitionUtil was deprecated was that people were making a mess of their data using it to do that.

There is a much lower-code option here.  I'm going to think in simple approval flows I have used before, and my sample workflow section to explain is:

• Needs approval -> Approved  (Yep, I approve that)
• Needs approval -> Rejected (No, don't do it)
• Approved -> In dev (We'll start working on it)
• Rejected -> Approved (Reason for rejection fixed, go for it)
• Rejected -> Rejected (You have tried to fix the reason I rejected it, but it's not good enough)

The last two are the important ones here.  Sticking with a simple trigger like the one you mention (custom field = X), then I would code a condition for 

If custom field = X, then return true

And put that on the "Rejected -> Approved" transition.  

That would hide the "approved" from the users until someone set the custom field.  You could also do it as a validator, so they would have to fill in the field during the approval.

In most cases where I've done something like this, it's going to the same status each time and we've used two conditions. So:

Green -> Red  (Condition:  "If colour-cf = blue, return true")

Green -> Red  (Condition:  "If colour-cf != blue, return false")

This way, the users only ever get offered a single transition (which usually then has different post-functions or validators!)

[Gal Zemah]

First, thank you.

To the point, you're right that your suggestion is a better way to implement this scenario.
But, unfortunately, not always have the option to do what we want, there are constraints.
In my case, it's existing functionality in the system and I must keep it as is.
For now, it's implemented via workflowTransitionUtilis in Jira 8.x and it works fine, but this option is deprecated in version 9.x, so I'm just trying to use issueService instead of workflowTransitionUtilis in order to do the transition.

Why issueService.transition is not working?
There is another way to make a transition in Jira 9.x version?

[Nic Brough -Adaptavist-]

It does not work because it can tell the issue is in a state of flux and hence not ready to be transitioned.  

You need to move to doing this properly, which means "not in a post-function".  Whether that's creative workflow conditions and validators, or "fast track" transitions, or listeners, or something else, I can't tell you in this case, just offer some options.  Your current implementation has to change, you do not have a choice.

[Gal Zemah]

Again, this logic works well via workflowTransitionUtil (no issueService).

Can you please elaborate on why the same logic works well if I'm using workflowTransitionUtil and not issueService?

[Nic Brough -Adaptavist-]

It does not.  You are getting lucky in that there is nothing in your issues that might break.

You need to stop using this and move to functions that work outside post-functions.