Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Next challenges

Recent achievements

  • Global
  • Personal


  • Give kudos
  • Received
  • Given


  • Global

Trophy case

Kudos (beta program)

Kudos logo

You've been invited into the Kudos (beta program) private group. Chat with others in the program, or give feedback to Atlassian.

View group

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

Anonymous User can change the state in a JIRA workflow

We have enabled Anonymous users to allow people outside R&D to add comments to JIRA issues. The weird side affect of this is our R&D people can now change the workflow state without signing in. How do I stop Anonymous users from changing a workflow state?

1 answer

0 votes

Ah, this is a common oversight for new administrators. It really is not obvious, and we've all done it.

Your workflow does not have any "conditions" on the transitions, which leaves them open to any user. Edit your workflow, and for every transition, add at least one condition. "User is in role of User" or "User is in role of developer" are pretty good default ones.


I don't know if I agree with your assessment that this is an "oversight" for new administrators. We have a LOT of transitions. For one project I think there are close to 50. I don't know if that's good practice, but I think that's irrelevant. There is a "permissions" page for a project. I should be able to set all the permissions for a project from this page. If I have everyone locked out of a project on the permissions page except for a certain team, and someone from another team (or worse, and anonymous user) can execute the workflow of that project, I'd call that a bug.

I understand the need to give people outside your team the permissions to execute workflow transitions (QA team moving something from "In QA" to "Ready for prod" for instance. But those should be the exception. I should be able to, from the permissions tab for my project, set a "default" permssions for transitions in my workflow. Then if the transaction doesn't explicitly state a set of permissions, it falls back to the default.


Mmm, an "oversight" is an unintentional failure to do, or notice, something that needs dealing with.

In this case, your admins didn't know they need to apply conditions to the workflow.

It is not intuitive, certainly, but it's not a bug. It's a consequence of having a very flexible way of doing permissions. Changing it wouldn't help, but setting it up the way I think you're suggesting in your first paragraph reduces the flexibility.

But, I also agree that there should be a "default" condition setting in the permissions.

I've not thought of it like this before, but your suggestion in your second paragraph is the best way to fix it that I've seen yet. Adding a line to permissions that says something like "can use basic transtion", and then having a fixed condition of "must be allowed basic transition" that is always applied would work very well. As long as your admins remember to add people to the permission (I'd also set a default of "user, developer and admin roles", to make it obvious and help them out)

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