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

0 votes
Accepted answer

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".

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?

0 votes

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.

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

0 votes

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.

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
Community showcase
Published Jan 08, 2019 in Jira

How to Jira for designers

I’m a designer on the Jira team. For a long time, I’ve fielded questions from other designers about how they should be using Jira Software with their design team. I’ve also heard feedback from other ...

1,154 views 5 10
Read article

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