It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

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

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}}


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


Thank you in advance.

1 answer

1 vote

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:

curl -D- -u username:password -X POST --data @/path/to/test.json -H "Content-Type: application/json" ""

AND on Cloud, following the format in:

curl -D- -u<API_TOKEN> -X POST --data @/path/to/test.json -H "Content-Type: application/json" https://<BASE_URL>

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.


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!

Like Earl_McCutcheon likes this

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:

Screen Shot 2019-11-01 at 1.16.58 PM.png

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:

Screen Shot 2019-11-01 at 1.18.28 PM.png

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.


Suggest an answer

Log in or Sign up to answer

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you