nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

permissions trouble after upgrade

kris11

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?

Accepted answers

Nic Brough -Adaptavist-

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

All comments

Nic Brough -Adaptavist-

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

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

kris11

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?

Nic Brough -Adaptavist-

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.

kris11

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

Nic Brough -Adaptavist-

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.

kris11

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!