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?

6 answers

1 accepted

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

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

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?

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

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.

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

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.

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

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