I am trying to update a resolution on Jira task such as to “Closed” or “Done” using https://tripactions.atlassian.net/rest/api/3/issue/{issue_key}/transitions
But I am getting an error:
{
"errorMessages": [],
"errors": {
"resolution": "Field 'resolution' cannot be set. It is not on the appropriate screen, or unknown."
}
}
I think the transition id is correct in my request and I have a write permission as well but
it appears all my issue transitions have no screen and that’s causing the error.
If that’s correct, is there a way to perform an issue transition without the screen?
Actually I’m facing the same issue where I’m trying to transition via the transitions API but getting the error :
"errors": {
"Change reason": "Field 'Change reason' cannot be set. It is not on the appropriate screen, or unknown."
}
Now, the field is in 3 screens (View, create, edit issue) I see for this particular project and issue type but still I get this error. Question is which screen is this transition error referring to.
Hey @david2 , can you tell me the steps to do that? I was unable to find screen for transitions. Just view, edit, create issue screens.
Note. There is no transition screen configured for this project, just transition validators have been used.
Thanks for the info @david2 .
I was able to add the transition screen as suggested. The mandatory field validation is there too on the screen when I do it on the atlassian platform.
But, strangely I still get the same error when I hit the API to do the transition.
Thanks for the additional context of screen shots. I noticed that your API request is trying to set a value for the field “Change reason” but the API wants a field id and will not accept a name instead. You’ll have to find the field id and use that in your API request.
@ibuchanan Perfect!!
This is what I was missing.
So I’m assuming that all the custom fields need to be updated by putting in the IDs, and for default fields, we can just use their “names”.
Be careful. Some of the “out of the box” fields that you would assume could be referenced by name are implemented with the same custom field approach you would use for configuration. As examples:
The fields for summary and description are true “system fields” where the names are fixed.
Generally, the things in the Jira platform, common to all Jira products, are true system fields. The things added per-product are the fields that take special care.
In any case, I’m glad you were able to make progress.
@ibuchanan okay understood, that is still manageable by calling the fields API.
But in these cases I have seen different payload requirements, when do we use ‘value’, when is it ‘name’ when is it just direct values for a particular field?