How to Update Issue status in cloud using REST API

Hi All,

when am try to update issue status using REST API its showing below error

{"errorMessages":[],"errors":{"status":"Field 'status' cannot be set. It is not on the appropriate screen, or unknown."}}\

my request json is:

" update " : {
" comment " : [{
" add " : {
" body " : " Status Change to Done "
"fields" : {
"status" : {
"name" : "Done",
"id" : "10001"

please can anyone help me on this issue.

3 answers

You can not change the status as a field - you must transition the issue - see the REST Endpoint documentation for:

POST /rest/api/2/issue/{issueIdOrKey}/transitions

But this is of course absurd, since it greatly increases the cost of performing bulk operations across multiple tickets.  At the very least there should be a per-project endpoint giving the possible set of transitions per issue type.

Nonsense, it's not in the slightest bit absurd.  Imagine two issues of the same type at two different points in the flow.  Your "per project endpoint" suddenly becomes useless as it has to cover every single transition possible across everything.

Not grasping how it would be "useless" to be able to obtain all the possible transitions for a project or even an issue type  in one shot, rather than only those possible at one particular state in the flow.  Why force the client to make multiple REST calls per issue when performing a single operation many times?

Ok, lets say you get all the possible transitions for a project, and it tells you

  • 100
  • 110
  • 120
  • 120
  • 120
  • 130
  • 130
  • 140

My issue is in status open.  Which one of these is currently valid?

Your example seems rather contrived.  Of course one would not want this.  Just as one can (painfully!) learn by parsing the XML returned by the "workflow" endpoint which transitions are possible from which states, any result returned here would have to include the "from" states for each transition -- not just the "to" state -- to be relevant or useful for more than a single issue.

It's not in the slightest bit "contrived", it's a real example from a simple Jira.  If you want to look into it more, consider the lines with more data:


  • 120: Open -> In Progress
  • 120: Open -> In Progress
  • 120: Open -> In Progress

Please tell me which one of these I need for my issue?

The point here is not about contrived examples, it's that the call to get the available transitions for an issue makes sense.  It's not absurd to say "you can do this with this issue", but it is absurd to have something that says "you can do some of these things with some of the issues on this list".

This seems like a failure of orthagonality with other elementary parts of the API.

I can get all the create metadata I want in one shot (controlling expansion appropriately so I only have to parse as much as I want); same for edit metadata.  If I'm performing operations in bulk, this is sensible and efficient.

But if I want to transition issues between states in bulk, I've got to do multiple calls per issue - even though the possible state transitions are a property of the state machine, ("workflow" in JIRA parlance of course), not, actually, some particular issue which is, of course, merely an instance of the state machine.

Of course I can parse the XML from the workflow endpoint to discover the state machine, but that just goes to illustrate that this is a thing that people reasonably want to do and that parsing vestigial XML from legacy APIs should not be necessary to do it.

You won't have to look far to find other people complaining about this.  What we have in common, I think, is that we are trying to build bridges between JIRA and other datastores, synchronizing data as appropriate.  Perhaps it is not entirely accidental that the design of this particular operation makes that more of a nuisance to do than I think it ought to be.

I think you need to go back to thinking about what you're actually trying to find out about the issues.  I don't see that "you might be able to do some of this list of things with a sub-set of this pile of issues" is a lot of use compared with "for each issue, here is a list of exactly what is currently possible"

I do have to look far to find other people complaining - you're the only one so far.

But, I do think I may be misunderstanding the problem.  Could you explain what you are trying to do, rather than what you think is wrong with the calls?

I don't think this discussion's going far.

Since a trivial Google search actually reveals at least 5 other threads either complaining about not being able to retrieve all the transitions for a project or unfavorably comparing the transitions and workflow endpoints, my take on this is that you're committed for some reason to the present design and uninterested in hearing that it might be suboptimal.  And  it certainly doesn't seem like we're going to get far with a discussion of species and genera or tokens and types.

Never mind whether, given JIRA's characteristically zippy response latencies, halving the number of queries for an operation spanning thousands of tickets might be a thing one might want to do, absent any aesthetic or practical concerns about the API itself.

So, we've got little to discuss.  Got it.  I'll desist.

No, you're utterly wrong again.

I can't find people complaining about not being able to get a list that they can't use for bulk operations because it tries to tell them all the options outside the context of the the issues they need to work with.

I'm not "committed to the present design", I'm trying to understand what possible use a list of transitions that might or might not apply to the issues I want to transition might be.  When I'm working on this, I need to know what I can do for each issue, not just get a list of what might be possible that I then have to do either repeat calls for for each issue, or make assumptions in my external code (especially as someone could easily change that)

I ask again - could you explain what you're trying to do?  If it's "transition a list of issues", then could you explain how a list of transitions that only might be valid for any single item is of any use?

0 votes

Status is not a "field", it's an indicator of position in the workflow.  You have to use transitions to change the status.

For REST, see the REST Endpoint documentation

Oops.  Sorry, Petar beat me to it.

curl  -u user:api-key -X GET -H "Content-Type: application/json"  https://{your}{key}/transitions | python -m json.tool

--view your transition state ids--

curl  -u user:api-key -X POST -H "Content-Type: application/json" -d @close  https://{your}{key}/transitions

cat close


  "transition": {

        "id": {your status id}


Suggest an answer

Log in or Sign up to answer
Community showcase
Posted Oct 09, 2018 in Jira Core

How to manage many similar workflows?

I have multiple projects that use variations of the same base workflow. The variations depend on the requirements of the project or issue type. The variations mostly come in the form of new statuses ...

244 views 6 0
Join discussion

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you