Transition issue with optional resolution fails via REST

[Marius Shekow]

I'm using the Atlassian C# SDK (which uses REST under the hood). I would like to transition an issue into the "Resolved/Closed" state. This does work on some Jira servers, but on one specific Jira server (v8.20.20) it does not.

The error message is: Field 'resolution' cannot be set. It is not on the appropriate screen, or unknown.

Code:

var resolutions = await jiraClient.Resolutions.GetResolutionsAsync(); // to determine the resolution ID
var testIssue = await jiraClient.Issues.GetIssueAsync("FOO-1234");
testIssue.Resolution = new IssueResolution("some-valid-resolution-id");
var available = await testIssue.GetAvailableActionsAsync(); // to get the transition ID
await testIssue.WorkflowTransitionAsync(some-valid-transition-id);
/*
Makes REST Call (POST) to http:.../rest/api/2/issue/FOO-1234/transitions
{
  "transition": {
    "id": "some-id"
  },
  "fields": {
    "resolution": {
      "name": "Done",
      "id": "10000"
    }
  }
}
*/

Closing the issue on Jira's web interface works fine. What's weird is that the web-tools of the browser tell me that the Resolution field shown in the web form is a (non-mandatory) field named

customfield_11338 which is not listed when I call http://.../rest/api/2/issue/createmeta?expand=projects.issuetypes.fields&projectKeys=FOO&issuetypeIds=<my-issue-type-id> or http://.../rest/api/2/issue/FOO-1234/editmeta

Any advice?

[Florian Bonniec]

Hi @Marius Shekow 

Resolution is mandatory as long as it's in the transition screen. If it's not it's not mandatory. If you try to set the resolution it has to be in the transition screen. So I guess the resolution is not set using the web UI, or if there is any value it's set using a post function.

You should not include the resolution if set using the postfunction or add the resolution field in the transition field of the transition you trigger

Regards

[Nic Brough -Adaptavist-]

That's not strictly true.  In Jira speak, "mandatory" means that a field must be filled.  From the initial creation, through transitions, and during edit.

Resolution is not mandatory - you don't have to enter it to create, edit, or transition an issue.

But when you put it on a screen, it always defaults to a value, and there is no way to select "none" (meaning leave it empty), so it always gets set.

But I suspect you are completely right on that the resolution field is not on the transition screen for the transition being called.

The reason I've explained all of that is that whilst the fix is to add resolution to the transition screen, you need to make sure that you do not put it on a create or edit screen!

[Marius Shekow]

This is how the transition screen (called "Resolve_Issue_Screen_Story") looks like:

As you can see, the field is called "Resolution", and you can select "None" (which is selected by default). And, as I said initially, this is a custom field that someone just named "Resolution", and I guess that some Post function takes that field's value and converts it to the real "resolution" field. I'm not a Jira server admin, so I cannot confirm this (when editing the workflow's transition, the Post-function is not a clickable link).

What I'd like to know is whether we really need to change the transitions or transition screens, or whether there is some other way that allows me to transition the ticket to "Closed" via REST. After all, it is possible to close the ticket via the web UI, so why should it be impossible via REST?...

[Florian Bonniec]

It's not recommanded to create csutomfield with the same name as system field. You need to update the resolution customfield not the resolution system field in that case.

resolution should not be in the payload you send but customfield_XXX where XXX is the field id of your custom resolution field.

customfield_XXX:{"value": "YYYYY"}

[Nic Brough -Adaptavist-]

Yep, the resolution field you have is useless, it's a botched fix for a non-existant problem, made by someone who doesn't understand how Jira works.

You need to remove that botch, get rid of the pointlessly duplicated resolution field, and go back to using the system resolution field.

There's no way you'll be able to use your REST calls until you get rid of this botch.

[Marius Shekow]

Thank you for this assessmen, Nic.

Florian, I did try to send the field along, but it did not work.

Request:

{
  "transition": { 
    "id": "41"
  },
  "update": {
    "customfield_11338": {
      "value": "Done"
    }
  }
}

Response: Can not deserialize instance of java.util.ArrayList out of START_OBJECT token

[Nic Brough -Adaptavist-]

My guess would be your not-resolution field (please, at least rename it, to avoid confusing people) may be a multi-select field. 

Your payload is sending a single option, but the field expects an array (even when there's only one option to send)