permissions trouble after upgrade

I have a project that has permissions for editing tickets (and various other actions) set to a specific project role only. I've just been notified that someone was able to change the status of the ticket without being logged in. This is the third such similar episode reported since our upgrade a couple weeks ago. Anonymous users are allowed to browse projects, but shouldn't the permissions scheme prevent this type of edit?

Any idea what's going on?

6 answers

1 accepted

This widget could not be displayed.

Ah this is a classic. Your permissions scheme probably hasn't got what you need in it.

Look at the workflow for the transitions they managed to do. You will find a section on "conditions" - these basically say "person must match this logic to be able to do this transition". If they're blank, or wide open (e.g. "person is in jira-users), then they will be able to do the transition. As you've said "not logged in", I'm 99% certain you'll find there are no conditions in your workflow! Have a look at the built in default too as an example - that has at least one condition on every transition.

Note that your permission scheme may be the problem, indirectly. The conditions you can put on are things like "assignee" or "reporter", but also "has permission X".

This widget could not be displayed.

Thanks Nic - we do this on some of our workflows. Here's my question about that. Why is it necessary? Logically it seems to me if the permission scheme says "these are the people that can edit" then why isn't that enough?

This widget could not be displayed.

Because Edit is not Transition. It's almost guaranteed that you don't want everyone who can edit to be able to create/delete/move/close/open/authorise/etc/etc/etc

When I'm teaching people about workflows, I tend to tell them "always put a condition of 'in group jira-users' on conditions" to begin with, as that solves the anonymous transition problem, and gets them familiar with the idea. Then I usually move on a bit and say "actually, change that to 'in role of users'" and then build on it - "only close permission", "only authorisers role" and so on.

This widget could not be displayed.

So, the permission scheme is more of an overall permissions, which are then refined by the workflow conditions?

This widget could not be displayed.

I wouldn't put it quite like that. I'd say the permission scheme allows you a series of dynamic flags on an account based on pattern matching (the pattern matching is things like "is in group"). Many of these flags are used elsewhere, to control what a user can or cannot do, and one of those places is in another dynamic function in workflow conditions. My prose is poor on this one, I know, and I'm trying to generalise.

This widget could not be displayed.

I think I get it. It was strange that it came up right after upgrading, but possibly that's due to more users being logged out than usual. Thanks very much for taking the time to explain!

Suggest an answer

Log in or Sign up to answer
Atlassian Summit 2018

Meet the community IRL

Atlassian Summit is an excellent opportunity for in-person support, training, and networking.

Learn more
Community showcase
Posted Wednesday in New to Jira

Are you planning to trial, or are currently trialling Jira Software? - We want to talk to you!

Hello! I'm Rayen, a product manager at Atlassian. My team and I are working hard to improve the trial experience for Jira Software Cloud. We are interested in   talking to 20 people planning t...

97 views 1 0
Join discussion

Atlassian User Groups

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

Find a group

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

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you