Uploaded image for project: 'Jira Data Center'
  1. Jira Data Center
  2. JRASERVER-71292

Jira allows illegal edit (issue type) through /rest/api/2/issue/<ISSUE-KEY>

    XMLWordPrintable

Details

    Description

      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

      Attachments

        1. 2020-07-13_16-06-17.png
          2020-07-13_16-06-17.png
          263 kB
        2. 2020-07-13_16-36-38.png
          2020-07-13_16-36-38.png
          82 kB

        Issue Links

          Activity

            People

              klopacinski Karol Lopacinski
              smitra2@atlassian.com Suddha
              Votes:
              9 Vote for this issue
              Watchers:
              18 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: