JIRA REST 500 Error - Issue with single vs multiple create requests when using assignees

[Josh Bray]

Strange issue or maybe small overlooked syntax issue...

• I can create a single ticket that has an assignee and labels.
• I can create multiple tickets that do not have an assignee and labels.
• I generate a 500 error when trying to create multiple tickets with assignee and labels.

Not sure where the issue is coming from when I combine two working syntax into one?

Thanks in advance!

I can create a single ticket using the following:

{
"fields": {
"project": {
"key": "PROJECTKEYHERE"
},
"summary": "title of the ticket goes here",
"description": [
"body of ticket goes here"
],
"issuetype": {
"name": "Task"
},
"labels": [
"update",
"asms"
],
"assignee": {
"name": "person1"
}
}
}

and I can create multiple tickets using the following w/o assignee: 

{ 
"issueUpdates":[ 
{ 
"fields":{ 
"project":{ 
"key":"PROJECTKEYHEREA"
},
"summary":"Review site for core, plugin, theme updates.",
"description":{ 
"type":"doc",
"version":1,
"content":[ 
{ 
"type":"paragraph",
"content":[ 
{ 
"type":"text",
"text":"description"
}
]
}
]
},
"issuetype":{ 
"name":"Task"
}
}
},
{ 
"fields":{ 
"project":{ 
"key":"PROJECTKEYHEREB"
},
"summary":"Review site for core, plugin, theme updates.",
"description":{ 
"type":"doc",
"version":1,
"content":[ 
{ 
"type":"paragraph",
"content":[ 
{ 
"type":"text",
"text":"description"
}
]
}
]
},
"issuetype":{ 
"name":"Task"
}
}
}
]
}

But using the same syntax between the two, I generate the following 500 error:

{"errorMessages":["Internal server error"],"errors":{}}

Here is the JSON I am attempting to use which is valid, but generates the 500 error:

{ 
"issueUpdates":[ 
{ 
"fields":{ 
"project":{ 
"key":"PROJECTKEYHEREA"
},
"summary":"1 title of the ticket goes here",
"description":[ 
"body of ticket goes here"
],
"issuetype":{ 
"name":"Task"
},
"labels":[ 
"update",
"asms"
],
"assignee":{ 
"name":"person1"
}
}
},
{ 
"fields":{ 
"project":{ 
"key":"PROJECTKEYHEREB"
},
"summary":"title of the ticket goes here",
"description":[ 
"body of ticket goes here"
],
"issuetype":{ 
"name":"Task"
},
"labels":[ 
"update",
"asms"
],
"assignee":{ 
"name":"person1"
}
}
}
]
}

I did rule out any issues with getting caught in the captcha.  Just not sure why I can get one version of each working, just not when I combine them together. 

[Andy Heinzer]

Hi Josh,

This is a bit strange to see.  I think that the labels aspect here is a red herring.  Instead, I'm leaning more towards the recent changes to Jira Cloud's REST APIs noted here.  In that link you can read about Atlassian's changes to various REST API endpoints to remove the username field from being able to be used in various endpoints.  

In this case, I think it strange this works for the single issue to assign to, but I think this change could explain why you can create issues without an assignee, but not when trying to reference an assignee by their name or username.

In Atlassian's Jira Cloud REST API documentation: the current example of creating issues using the v3 endpoint of POST /rest/api/3/issue shows the new use of id instead of name.

    "assignee": {
      "id": "e5:e1a16c14-1fe0-1c93-a2b1-ac4493ace0f1"

I would be interested to see if you can try to first lookup the user account to find their id, and then use that value to try to set the assignee, instead of trying to set the assignee by name here.  If my hunch is right, then it probably explains why you're getting this error and in turn this will work to assign the issues.

One way to do lookup the user's ID via REST API would be to try to make a call to the endpoint GET /rest/api/3/groupuserpicker and pass it the query parameter of the username in question.  Here is an example in curl:

curl -D- -X GET -H "Authorization: Basic [redacted auth token]" -H "Content-Type: application/json" "https://example.atlassian.net/rest/api/3/groupuserpicker?query=Ellen"

This call can return multiple users that match the queried term, but each of them should have an accountId field value for their account.  See if you can use that accountID to assign the issues to instead.

{"users":{"users":[{"accountId":"43215deabcde0d2ff094a35a","accountType":"atlassian","name":"ellen.smith","key":"ellen.smith","html":"<strong>Ellen</strong> - ellen.smith@example.com","displayName":"Ellen"}],"total":1,"header":"Showing 1 of 1 matching users"},"groups":{"header":"Showing 0 of 0 matching groups","total":0,"groups

What specific endpoint are you using for creating these issues?  Are you using a different bulk create endpoint for creating issues en masse?

Please let me know the results,

Andy

[Josh Bray]

Thanks for the thorough response @Andy Heinzer !

I substituted name for ID via your recommendation:

 "assignee": { "id": "e5:e1a16c14-1fe0-1c93-a2b1-ac4493ace0f1"

and it did work in the single ticket creation instance, but not in the multiple instance.  I received the same 500 error.

I have been using endpoint https://company.atlassian.net/rest/api/3/issue/, which works for the single ticket creation using both name/id and the multiple ticket creation without using name/id.  Doesn't work for multiple ticket creation with name/id however.

That being said, I was able to get it working using https://company.atlassian.net/rest/api/3/issue/bulk and using id.

Suppose this is resolved for now and my confusion was between using /rest/api/3/issue and being able to create single tickets with user and multiple tickets w/o user/id and not realizing I should have been using /rest/api/3/issue/bulk the whole time. 

Still not sure why I could create multiple tickets without user/id with /3/issue, but not with user/id with /3/issue.  Had I not been able to create multiple tickets with /3/issue I would have caught on to having to use /3/issue/bulk sooner.

Thanks again for your help!

[Josh Bray]

@Andy Heinzer was my comment to you removed?  I'm not seeing it here anymore...  well I can see it via a private window but not when logged in.

[Andy Heinzer]

Hi Josh,

I think that our site's spam filter might have temporarily thought your response was spam.  We moved it back.  I believe it is there now and I can see it.   Are you still not able to see it on this thread?    From what you describe it sounds like this might not be a spam issue, but a problem with the way some content is displaying on the page for your specific account. 

Please let me know either way.

Sorry for the inconvenience.

Glad to hear that you got the REST issue resolved.

Andy

[Josh Bray]

Still can't see it for whatever reason - even when accessing my posts via my profile.  Thanks again for the help!

[Andy Heinzer]

That's bad.  Thanks for letting me know.  I've tried to like your reply, curious if you get a email notification about a liked post for it.  It's there.  I'm creating an internal ticket about this. 

I've seen this problem before on our site, but only like 2-3 times.  It tends to correct itself before we can properly investigate it.  I'll push back on my site support team to see if we can learn more about this.

[Josh Bray]

I did receive that notification and now that you mention it, I can now see the comment and it is now reflected in the Posts section of My Profile.

¯\_(ツ)_/¯