Assignee set to unassigned while creating ticket through the rest API

Benjamin Caillat

Hello,

I am having some issue setting the assignee while creating a ticket or updating an existing one through the REST API.

For example, if I have a ticket and run the following command:

curl -D- -u xxx:xxx -X PUT --data '{"fields":{"assignee": {"name": "xxx"}}}' -H "Content-Type: application/json" https://xxx.atlassian.net/rest/api/2/issue/xxx

I do not get any error, but the ticket is not updated.

Note that updating the summary for example works, so it seems to be something related to the assignee itself. Does anyone knows how to solve this?

Thank you for your help,

B.

Andy Heinzer

Hi Benjamin,

I see that you are using the REST API for a Jira Cloud site, but it appears there is a problem trying to change the assignee of an issue there.  There are actually a couple of different factors here I think are contributing to the confusion here.  I thought I would document my troubleshooting steps here to help explain this better.

You could try an alternative endpoint to just update the assignee in PUT /rest/api/2/issue/{issueIdOrKey}/assignee.  But when I try this with a payload of just {"name": "exampleUsername"} I get back an error of:

{"errorMessages":["'accountId' must be the only user identifying query parameter in GDPR strict mode."],"errors":{}}

This is due to the changes in Jira Cloud around usernames due to GDPR privacy.  More details in Deprecation notice and migration guide for major changes to Jira Cloud REST APIs to improve user privacy.  You are welcome to read through this for more background, but the gist of this is that we can't use username for all the endpoints like we used to be able to do.

So instead of supplying the 'name' of the user account in this REST call, we need to supply the 'accountId' of that desired user account.  You can find this by first calling another endpoint of Find users assignable to issues GET /rest/api/2/user/assignable/search.  This endpoint will give us the accountId, but only for users that can actually be assigned to that issue. For my site, I have an issueKey example called SCRUM-37, and an example username called 'yahandy'.  For me this curl REST call looked like this:

curl -D- -X GET -H "Authorization: Basic [username+tokenEncodedStringHere]" -H "Content-Type: application/json" "https://[myCloudSite].atlassian.net/rest/api/2/user/assignable/search?issueKey=SCRUM-37&query=yahandy"

This returned for me a single user, but depending on your search term and assignable users, you might get more than one user account back by this query.

[{"self":"https://[myCloudSite].atlassian.net/rest/api/2/user?accountId=123456:44448ae7-90ce-4e62-bfda-e88abcde5555","accountId":"123456:44448ae7-90ce-4e62-bfda-e88abcde5555","accountType":.....

I was able to extract yahandy's accountId in the response to just copy

"accountId":"123456:44448ae7-90ce-4e62-bfda-e88abcde5555"

(Note: This is not the actual accountId of my test account, I have altered the characters here just so you could see and understand the format this field will have in relation to user accounts.)

And in turn use this accountId as a means to set the assignee when using the PUT /rest/api/2/issue/{issueIdOrKey}/assignee endpoint.  I then went back to the original endpoint you were trying to use here of Edit issue PUT /rest/api/2/issue/{issueIdOrKey}, I was also able to use the accountId here instead of the name parameter to edit that field value for that issue.  And it works.

curl --request PUT \
> --url 'https://[myCloudSite].atlassian.net/rest/api/2/issue/SCRUM-37' \
> --header 'Authorization: Basic [username+tokenEncodedStringHere]' \
> --header 'Content-Type: application/json' \
> --data '{"fields":{"assignee": {"accountId":"123456:44448ae7-90ce-4e62-bfda-e88abcde5555"}}}'

I too get essentially no response from this curl PUT call from my Cloud site, but this does work to change the assignee of the issue.  I believe this is because the PUT request is not exactly malformed, because not specifying the accountId value is the equivalent of unassigning the issue.  This does make some sense because having no assignee is effectively a NULL value for that issue field.

Sorry this is an extra step to make this kind of change, but I hope this helps to explain the current behavior and how you can work past it.

Andy