Changing status/transition via API

Valandriel Sun

Hi there,

I'm currently working on some C# code using the Atlassian SDK that shall read and edit project contents and some other data from a test environment, both cloud and from a local test instance. So far the reading part is done and working very nicely. Troubles start when I try to change an existing issue, changing the current state/status in particular.

What I do first is this:
I fetch all available states via Atlassian.Jira.Jira.Statuses.GetStatusesAsync();
Then on the Issue instance I try to set a new IssueStatus but when I try to call SaveChanges() on that issue it doesn't work.

I came across the method Issue.WorkflowTransitionAsync(string actionNameOrId) which I guess would finally make the ticket switch to a new status, but how do I know which actionNameOrId is the correct one?

In order to solve that issue I think I first need to get more clarity on the process itself. Therefor I'd like to ask some questions within this context and hope someone is able to answer them.

1. Is there any way to retrieve allowed states per issue type or maybe per project? I only seem to be able to get a list of all states available on the Jira instance.

2. Is setting a status even considered the right way of changing a ticket's working state or if not are transitions the right approach?

3. How are transitions and (allowed) states connected and how can I find these relationship from the API? By calling rest/api/2/issue/{issueId}/transitions?expand=transitions.fields I actually do receive a set of transitions but they dont contain any reference to any status but rather to resolutions, are the latter in any way related to status?

I think this is more an issue of understanding the business process than understanding how one would use the API's facilities and hence I tried to get answers from the documentation. While it was very useful even with examples on most topics I had no luck trying to understand the things discussed above. Should there be any reference, documentation, examples etc. please point me in the right direction. I hope this is the intended location to ask this kind of question(s), if not please correct me.

Thanks in advance, any hint is very much appreciated.

Nic Brough -Adaptavist-

Welcome to the Atlassian Community!

You're going in the right direction. 

On question 2:  Yes, transitions.  You can not just set an issue status, it's not really a field, it's a display of where the issue is in its lifecycle.  (You can actually code something that will change the status directly, but if you do, all that happens is you end up with a broken issue, because status change is more complex than just setting it)

So, yes, setting a status is actually done by performing a transition.

On questions 1 and 3, it's the workflow.  Every issue type in a project is set to use a workflow.  Often they share them (across projects, let alone just issue types - I'd say most projects I see have a single workflow, and it's often groups of similar projects all using the same one)

 

And so, your REST call in question 3 is the way to go.  It gives you the set of transitions that a person can perform on the current issue you are looking at.

But I think you may be misreading the "to" section of the response.  That all relates to the target status of the issue.  The docs have the example that is

{ "expand": "transitions", "transitions": [ { "id": "2", "name": "Close Issue", "opsbarSequence": 10, "to": { "self": "http://localhost:8090/jira/rest/api/2.0/status/10000", "description": "The issue is currently being worked on.", "iconUrl": "http://localhost:8090/jira/images/icons/progress.gif", "name": "In Progress", "id": "10000", "statusCategory": { "self": "http://localhost:8090/jira/rest/api/2.0/statuscategory/1", "id": 1, "key": "in-flight", "colorName": "yellow", "name": "In Progress" } },

Note that the "to" points to a rest call to get a status (10000), name "in progress", and a block of statusCategory stuff - that's all about the end status of the transition.

Resolution is a separate field.  Technically it actually has precisely nothing to do with status, and us admins always have to think about resolution when we're building workflows, because we usually need to set and clear resolution as we move an issue into certain status (set resolution when moving to "closed", clear it when re-opening is the short version)

 

The bad news here is that the transitions call is for a current issue.   If you want to understand the whole workflow (all status and transitions between them), you're going to have to do quite a lot of code - there are calls you can make to retrieve a workflow, bit gives you a load of XML you'll need to parse for all the transitions and status.