Issue Summary

Jira doesn't error out if we edit the issue type from REST API to a value which is not allowed. Issue with issueType="X" can be changed to issueType="Y" even though X and Y don't share the same workflow if done from REST API.

Steps to Reproduce

• Create two issue types (Example: "Support" & "TR")
• Make the two issue types tied to two different workflows
• Create an issue of issueType="Support"
• Edit the issue Type to TR from REST:

  curl -v -X PUT "<BASE-URL>/rest/api/2/issue/<ISSUE-KEY>" --header 'Content-Type: application/json' --data-raw '{"fields":{"issuetype":{"name":"TR"}}}' -u admin:xxxxx

• Resulting issue will not act according to the new workflow

Expected Results

Jira throws error response code as Illegal action

Actual Results

Jira responds with 204 and the new issue type shows inconsistent workflow state and transition options:

$ curl -v -X PUT "http://localhost:8854/j854/rest/api/2/issue/TORF-13" --header 'Content-Type: application/json' --data-raw '{"fields":{"issuetype":{"name":"TR"}}}' -u admin:XXXXX
*   Trying ::1...
* TCP_NODELAY set
* Connected to localhost (::1) port 8854 (#0)
* Server auth using Basic with user 'admin'
> PUT /j854/rest/api/2/issue/TORF-13 HTTP/1.1
> Host: localhost:8854
> Authorization: Basic YWRtaW46Q2hhcmxpZSE=
> User-Agent: curl/7.64.1
> Accept: */*
> Content-Type: application/json
> Content-Length: 38
>
* upload completely sent off: 38 out of 38 bytes
< HTTP/1.1 204
< X-AREQUESTID: 965x1831x1
< X-XSS-Protection: 1; mode=block
< X-Content-Type-Options: nosniff
< X-Frame-Options: SAMEORIGIN
< Content-Security-Policy: frame-ancestors 'self'
< X-ASEN: SEN-500
< Set-Cookie: JSESSIONID=4A90632BC6AF13A8A018C0110904A860; Path=/j854; HttpOnly
< X-Seraph-LoginReason: OK
< Set-Cookie: atlassian.xsrf.token=BJ9S-9F4Z-WN42-OUGU_3282c73058e7f3a272003c23c222947d48a6627a_lin; Path=/j854
< X-ASESSIONID: ayfao0
< X-AUSERNAME: admin
< Cache-Control: no-cache, no-store, no-transform
< Content-Type: application/json;charset=UTF-8
< Date: Mon, 13 Jul 2020 10:35:07 GMT
<
* Connection #0 to host localhost left intact
* Closing connection 0

Workaround

NO known workaround to make jira stop this action from REST.

From customer's perspective below are the workaround options to get the affected issue keys back to working state:

• Run Integrity checker to find affected issue keys
• Use the same endpoint to set the issue type back to original issue type and then use the UI and Move the issue to the new issue type instead of edit
• Cloning the issue gets the current workflow status(es) and Transition(s) to show up
• Make both of the issue Types share the same workflow rendering this bug not applicable to begin with