How to Update Issue status in cloud using REST API

[Radhakrishna_Sangishetti]

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.

[Petar Petrov (Appfire)]

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

[Thor Simon]

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.

[Nic Brough -Adaptavist-]

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.

[Thor Simon]

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?

[Nic Brough -Adaptavist-]

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?

[Thor Simon]

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.

[Nic Brough -Adaptavist-]

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".

[Thor Simon]

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.

[Nic Brough -Adaptavist-]

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?

[Thor Simon]

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.

[Nic Brough -Adaptavist-]

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?

[Joshua Landman]

curl  -u user:api-key -X GET -H "Content-Type: application/json"  https://{your}.atlassian.net/rest/api/2/issue/{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}.atlassian.net/rest/api/2/issue/{key}/transitions

cat close

{

  "transition": {

        "id": {your status id}

  }

[Nic Brough -Adaptavist-]

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

[Nic Brough -Adaptavist-]

Oops.  Sorry, Petar beat me to it.