JIRA REST API transitioning of issues on a Kanban board not working

[Agronomos123%]

I am trying to drag and drop an issue (Transition it) on a Kanban board; I am using the REST API, but the action does not affect the status on the board.

This is my code (python function):

def get_ticket(issueID,state):
'''
Transition ticket into the next status
'''
server = url + "rest/api/2/issue/" + issueID +'/transitions?expand=transitions.fields&transitionId=' + str(state)
headers = {
"Accept": "application/json",
"Content-Type": "application/json"}
payload = json.dumps( {"transition": {"id": state} })

response = requests.request(
"POST",
url,
data=payload,
headers=headers,
auth=HTTPBasicAuth(user, apikey)
)
print("Status: ",response.status_code)
return(response)

I have checked the valid transition states and got this (hiding some information for privacy reasons):

{'expand': 'transitions',
 'transitions': [{'id': '51',
   'name': '<test label>',
   'to': {'self': 'https://<server/rest/api/2/status/10158',
    'description': '',
    'iconUrl': 'https://<server>/images/icons/statuses/generic.png',
    'name': '<test label2>',
    'id': '10158',
    'statusCategory': {'self': 'https://<server>/rest/api/2/statuscategory/2',
     'id': 2,
     'key': 'new',
     'colorName': 'blue-gray',
     'name': 'To Do'}},
   'hasScreen': False,
   'isGlobal': False,
   'isInitial': False,
   'isAvailable': True,
   'isConditional': True,
   'fields': {},
   'isLooped': False}]}

I have tried to use the next state as '51' or '10158' or '2', both as digit and as text; also, I have tried the address with and without the transitionId attached at the end, but the transaction does seem to have any effect, and none of them get any errors.

Any guidance over what I might be missing is appreciated.

[David Bakkers]

Hello @Agronomos123% 

Your URL is incorrectly formed. The expansion= parameter is used for expanding the value for fields with a Get Transitions request. Since the Transition Issue endpoint doesn't use that parameter, expansion= has no purpose, so the rest of the URL is probably being ignored.

Your request URL should be just:

server = url + "rest/api/2/issue/" + issueID +'/transitions'

The body of the request is the only place you need to define the other parameters for transitioning the issue. You don't need to do it in the URL and the body, as that duplication might also be confusing the REST API.

Have another look at the Transition Issue section of the Jira Cloud REST API documentation page. There is a Python example there that shows the structure of the request.

[Agronomos123%]

Thanks, @David Bakkers 

I believe I started there (at the plain endpoint) and started adding things when it didn't work; I will try again today.

Could you help me understand, on the provided example, what should be the right transition state ID for the next valid state? Should it be "2", "10058," or "51."?

[David Bakkers]

The REST API doesn't know what status for the Issue is 'next', only you do, or, more accurately, what the workflows dictates, since the workflow may allow an Issue to transition to any status from any other status with no intermediate status needed. It's up to you to know or lookup what transition state the Issue is currently in, what state you want it to be in, then use the ID of that 'destination' transition state when changing the Issue

Do a Get Transitions request for the issue first. The response will list all the available transitions available with their ID and name. The response will be something like this:

"transitions": [
  {
   "id": "51",
   "name": "Testing",
   "hasScreen": false,
   "isGlobal": true,
   "isInitial": false,
   "isAvailable": true,
   "isConditional": false,
   "isLooped": false
},

So, let's say you wanted to move the issue to the status 'Testing', you'd use the transition ID of 51 in your Transition Issue request

If you want to know what the current status of the Issue is before you transition it to a new status, you have to look that up beforehand.

[Agronomos123%]

@David Bakkers

 Thank you so much for the answers; I must be missing something trivial that I cannot see. I already applied all the recommendations, and the command is still not working; follow the details:

My query now looks like this:

server = url + "rest/api/2/issue/" + issueID +'/transitions'
headers = {
"Accept": "application/json",
"Content-Type": "application/json"}
payload = json.dumps( {"transition": {"id": state} })

response = requests.request(
"POST",
url,
data=payload,
headers=headers,
auth=HTTPBasicAuth(user, apikey)
)

to get the current state, I am running: 

server = url + "/rest/api/3/issue/<issue-ID>/transitions"
response = requests.get(server,timeout = (10,10), auth=HTTPBasicAuth(user, apikey))

and I get the following response:

{'expand': 'transitions',
 'transitions': [{'id': '51',
   'name': 'Approve Tagging',
   'to': {'self': '<server>/rest/api/2/status/10158',
    'description': '',
    'iconUrl': '<server>/images/icons/statuses/generic.png',
    'name': 'Internal QC',
    'id': '10158',
    'statusCategory': {'self': '<server>/rest/api/2/statuscategory/2',
     'id': 2,
     'key': 'new',
     'colorName': 'blue-gray',
     'name': 'To Do'}},
   'hasScreen': False,
   'isGlobal': False,
   'isInitial': False,
   'isAvailable': True,
   'isConditional': True,
   'fields': {},
   'isLooped': False}]}

From your guidance above, I understand that I need to run my POST with a state of '51', so it would be something like:

payload = json.dumps( {"transition": {"id": "51"} })

response = requests.request("POST", URL, data=payload, headers=headers, auth=HTTPBasicAuth(user, apikey))

This command has no effect and receives a "200" status code which is not on the documentation (it should be 204 for successful transition); I have also tried with states of "10158" and "2" after the other potential IDs on the JSON of the valid states with the same outcome, a "200" status code, and no change.

At this point, I am not sure what else to try; any recommendations or guidance would be highly appreciated.

[David Bakkers]

When I try that method on my Jira Cloud instance, it works just fine and the issue transitions correctly using the first ID of 51 and the response from the REST API is a code 204, not a 200. There is no message in the response body, which isn't exactly informative, but at least it works.

Here is my request, which I tested using Postman:

I tried with both the v2 and v3 REST API endpoints and both worked exactly the same.

My only observations is that your workflow has additional conditions that need to be met to transition the issue, as indicated by the 'isConditional': True in the Get Transitions response. The conditions might be that particular fields need to have values and you will have to set those field values at the same time when you are doing the transition.

Try doing the issue transition manually to the state Approve Tagging via the web interface. What happens? Do you get a warning a field needs a value or similar?

I think you should have a closer look at the workflow itself and double check exactly what needs to be done to transition the issue to the Approve Tagging status  and what the required sequence is.

[Agronomos123%]

Thanks, when we do it manually on the Kanban board, we simply drag it to the next column; no warnings or additional actions are required.

If I understand the "Transitions" response correctly, the potential fields I can send are:

'name': 'Approve Tagging',
   'to': {'self': '<server>/rest/api/2/status/10158',
    'description': '',
    'iconUrl': '<server>/images/icons/statuses/generic.png',
    'name': 'Internal QC',
    'id': '10158',
    'statusCategory': {'self': '<server>/rest/api/2/statuscategory/2',
     'id': 2,
     'key': 'new',
     'colorName': 'blue-gray',
     'name': 'To Do'}},

right? I am excluding the ID since that one is on the "transitionID" on the payload.

I will try sending all these additional fields along with the transition information and see what happens.

I will keep you posted on the outcome.

[Agronomos123%]

@David Bakkers  I tried sending all the fields on the transition response, and there was no change, still getting a 200, and nothing happens.

Is there any way to query what could be the "conditions" for which the 'isConditional' component of the transition depends on?

I tried querying the workflow with '/rest/api/3/workflow/rule/config' but get a 403 error message since only "Connect Apps" can run that operation.

[David Bakkers]

Sorry @Agronomos123% but, that's as much as I know, as I've only used the REST API to transition issues using workflows that are non-conditional, so I have no further advice to provide.

You're going to need to read the REST API documentation more deeply and refer to other articles on the topic to work out how to query the workflow states, conditions etc. and work out what extra is needed to make that transition request work for your issues types.

Good luck on your learning journey.