[JIRA] Anonymous user can resolve and reopen issues. Why?

[Alexandr_Sirotkin]

Anonymous user can resolve and reopen issues in one of our project. In other our projects it is not allowed. All projects use the same Default Permissions Scheme. So it is strange. I need to restrict anonymous user only for view isses w/o any editing. Please help.

[Joe Pitt]

If they can view it, they can execute a workflow transition if it doesn't have restrictions. We restrict all transitions to the Assignee and in some cases roles. The idea is the assignee is responsible for the issue and no one should be moving it through a transition besides them. If they need to move it, say for instance the assignee is on vacation, they just assign the issue to themselves first. An anonymous user would never be the assignee so they couldn't move it.

[Nic Brough -Adaptavist-]

I'd also add that in Jira 6.3+, there is a new permission called something like "Can use transitions". This fixes the default "anyone can use a transition if they can see the issue" problem so you don't have to worry about it any more. Despite saying that it fixes it, I would still STRONGLY recommend that you think about your conditions while working with workflows at all times.

[Alexandr_Sirotkin]

Thanks all for fast answers! We are using JIRA v6.0.4.

I checked my problem project, its indeed has a custom workflow. I check a transition "Reopen", it has no any conditions. I add one: "Only the assignee of the issue can execute this transition." but it didnt help. Anonymous still can see "Reopen" button and can click it, and issue is reopened in this case. 

I also checked our default workflow which is used in the most of our projects. "Reopened" transition in it doesnt have any conditions but projects which use this workflow doesnt show "Reopen" button for anonymous.

Joseph, it not very obvious practice that if users can view an issue then they can do transitions. And for my JIRA instance it is not true since for projects with default workflow issues can be viewed by anonymous but can not be reopened.

May be I missed some simple thing in massive JIRA configuration mechanism, please narrow me. Our Project managers complain about every action which is done by anonymous user.

[Joe Pitt]

I don't know what could cause this behavior. I'd open an issue with Atlassian.

[Alexandr_Sirotkin]

We have a JIRA license, may be it is better to create "Support request"? Actually the problem project was heavily customized by one of our JIRA admins, so something could went wrong. May be our config files which are sent with the request can help here?

[Nic Brough -Adaptavist-]

Yes, a support request would be better. However, they are going to go into a lot of detail with your config, so it's worth trying to explain the complexities up-front.

[Rick Herrick]

I'm having this issue in JIRA 6.2.3. The ability to manage transitions (specifically, permissions on resolving and closing issues) is restricted to the Developers role. In what way does that mean that anonymous users should be able to change the workflow state? And if that restriction isn't enough to keep anonymous users from changing the workflow state, why would changing it to another restriction be enough? Also, we've had an anonymous user re-opening issues. As best I can tell, there's not even a setting in the permissions scheme for that, so how do we prevent it? This is pretty troubling to us, because we're trying to open up our main JIRA project to the public, but I open it up for a couple days and we have literally HUNDREDS of changes from an anonymous user in our project. These were mostly likely done by something automated that specifically looks for this vulnerability, although why I have no idea.

[Nic Brough -Adaptavist-]

The ability to use a transition is controlled by the "conditions" on them. Not the permissions. I find it better to think of permissions as "a set of flags to be used in other places, such as conditions (so I can say "only people with close permission can use the close transitions" ) ". If you have anonymous users able to transition issues, then your workflow needs conditions adding to them.

[Rick Herrick]

First, that is completely opaque and non-obvious. It may be "better to think of permissions" that way, but I assure you that in most cases people don't. Second, the idea that, regardless of how I might think of permissions, giving someone permission to browse issues in ANY WAY implies that they can change anything about those issues is... well, it's stupid. And third and finally, wow, what a tremendous pain in the ass to manage. I can't just set permissions on my project and expect anonymous bots to not be able to come modify my issues. Instead, I have to set permissions on my project and THEN go set conditions on every single state that might apply to an issue in my project. We'll be upgrading soon, so I realize that this goes away at least to some extent by having the permission to control transitions, but I'm kind of stunned that this sort of thing went on in JIRA for so long without having a fix for it.

[Joe Pitt]

It doesn't allow anyone or bots the ability to change anything. The 'hole' was they could execute transitions that weren't protected. They can't edit issues, add comments, add/delete attachments, etc. And unless you allow 'anyone' browse permission bots can't even see the projects because they don't have userids.

[Alexandr_Sirotkin]

Yes, but I failed to find out how to restrict Anonymous user using conditions on transitions. Probably its my fault, but if JIRA' settings would have a checkbox "dont allow to edit by anonymous" per project or smth like that it would make my life much easier:)

[Joe Pitt]

It sounds like you're resisting the solution of putting conditions on transitions. As NIc said, the way to control transitions is with conditions such as Assignee only, a particular project role, or assignee and project role.

[Alexandr_Sirotkin]

Oh, my question still being actual. I have to say that one of our team rejected to use JIRA in theirs work, and one of the reason was the issue from the topic. 

[Renjith Pillai]

It is not based on permission scheme. The workflow transitions require that Conditions are set so that only authorised people can execute the workflow transistion. Please check the workflow of the issuetype/project which is having this problem and add the necessary 'Conditions'