Can not change transition for the issue via API if it has a disabled user into Issue Watchers list

[Eugene Goza]

Hi, all!

We have a unexpected behavior when it is not possible to change transition via API endpoint in case of the ticket has a disabled user into the Issue Watchers list .

The same API call works fine in case of this user is not disabled

The questions are how to change transition in this case and why user status influences to this operation?

API call example: 

POST https://host/rest/api/2/issue/TEST-1111/transitions

Payload example:

{"update":{"comment":[{"add":{"body":"test"}}], "customfield_10601":[{"set":"TEST"}]}, "transition":{"id":61}}

Result:

{
"errorMessages": [],
"errors": {
"customfield_10400": "Users do not have permission to browse issue: test"
}
}

Thank you in advance.

[Earl McCutcheon]

Hi @Eugene Goza ,

Welcome to the community and thanks for reaching out. This on is proving a bit difficult to narrow down.

I just tested this out on a staging Jira Server installed locally as well as on my cloud instance, as I noticed that you have both "jira-server" and "jira-cloud" tags flagged on this post, Regardless I was not able to reproduce the behavior on either platform.

First off I just wanted to clarify a few points:

1. which platform you are on, so we can align testing, to verify if one of those tags were added by mistake or if you are seeing this on both platforms when running the equivalent calls
2. Also, if this is Jira Server, it could be an issue with the version you are testing on, so what Jira version are you running on for server
3. When you noted that there is a disabled user in the Issue Watchers list, how is the user disabled?  EXE, were they:
   1. Removed from all groups?
   2. Removed from application access?
   3. Removed from project roles or permissions?
   4. Deleted from user management system?

Next for some clarification on my tests to make sure I am following the same steps, I did a super simple test initially with a data package consisting of the transition only as well as some more complicated updates consisting of updating various fields that were present on the transition screen such as adding a comment and setting a resolution on transition to done.

I Used the following CURL formats Noting I tried with both "transitions" AND "transitions?expand=transitions.fields" AND  :

Server, following the format in:

• https://docs.atlassian.com/software/jira/docs/api/REST/8.2.0/#api/2/issue-doTransition

curl -D- -u username:password -X POST --data @/path/to/test.json -H "Content-Type: application/json" "http://127.0.0.1:63192/jiratest/rest/api/2/issue/BACON-7/transitions?expand=transitions.fields"

AND on Cloud, following the format in:

• https://developer.atlassian.com/cloud/jira/platform/rest/v3/?utm_source=%2Fcloud%2Fjira%2Fplatform%2Frest%2F&utm_medium=302#api-rest-api-3-issue-issueIdOrKey-transitions-post

curl -D- -u email@domain.com:<API_TOKEN> -X POST --data @/path/to/test.json -H "Content-Type: application/json" https://<BASE_URL>.atlassian.net/rest/api/3/issue/POTATO-53/transitions?expand=transitions.fields

With my basic test.json like the following (noting I had a few iterations that all worked ):

{
  "transition": {
    "id": "41"
  }

 Let me know what points I'm missing here and where the test's are not lining up so I can take a closer look.

Regards,
Earl

[Eugene Goza]

Thank you for your awesome answer. Some extra information for you:

1. it's dedicated JIRA server

2. JIRA v7.3.0

3. I can not answer the last question, I will try to find more information

Also I will try your information and check this again. Thank you a lot!

[Earl McCutcheon]

Hi @Eugene Goza ,

Thanks for the confirmation, and testing this out on a 7.3.0 installation was also Successful with the method I tried. 

So there is most likely something occuring with how the user account is configured.  Possibly a active directory sync issue, As you noted that you are already checking this, please do get the info on how the users account is configured, and how they were flagged as inactive.  In My test I had the test user added to the watcher list:

And then removed application access under User Management from the account, Noting the user is in the internal directory, and is not a member of any other groups:

Double check how the user is configured and let me know if the account is set up differently.  And I would also recomend checking the logging when you run the command to see if there are any explicit errors triggered that could point us to whats causing the failure, as something else could be failing in the background like a module in a system add-on or a conflicting user installed add-on.  If this is the case I would expect to see something output in the logging directly.

Regards,
Earl