Why can a user transition an issue if they only have browse project permissions?

[Karie Kelly]

We need the ability to lock down some projects, once done, to be read-only.

I have a permission scheme that is set for users to browse projects, but permissions to nothing else.

However, if a user navigates to that project, they can transition issues, regardless. They don't have edit, create or any other actions, but if the issue isn't closed and there are open transitions, they can transition them.

It seems that workflow transitions should also be grayed/not accessible because that is editing an issue - it is changing status, setting resolution, etc.

How do I completely lock out the ability for transitions to not be done.

[Nic Brough -Adaptavist- · Accepted solution]

Transitions aren't editing the issue, they're separate.

Open up the workflow and find a transition you need to protect. Look at it's "conditions". You will probably find there are no conditions, which means "anyone can do this". You want to add conditions like "user is in role of developer", "user has a certain permission" or "user is assignee" (you can combine them with and/or clauses).

[Karie Kelly]

That I cannot do because we have many, many workflows and they are shared across several projects.

I don't understand, though, a transition that changes an issues data (anything associated with the screen), is not editing the issue. Browse should mean read-only (imho)

[Karie Kelly]

Sure. But log work, comments, attachments, etc are all specific permissions called out in the permission scheme which we revoked as the intent really is to make the information read-only. It seems then beneficial if workflows are separate, they should have a similar permission option to align with the other actions referenced. Thanks!

[Nic Brough -Adaptavist-]

I'm afraid that's all you can do.

Browse permission really does mean browse. It just lets a user read an issue. The transistions in a workflow are separate from that, and by default, are unprotected.

I wasn't clear on "edit" though. "Edit" in a general sense does mean "changes data", but in Jira it is more specific - it really does mean "uses an edit screen to change fields". Other actions change data too, but are not "edit" because they need to be handled differently and they need to be distinct from simple updates. Workflow transitions are one of these, as are comments, logging work, and so-on.

[Karie Kelly]

No, i do understand. I have utilized many conditions, validators, and post functions in my workflows. But, because they are numerous and shared, I cannot edit those to just apply to specific projects. I would have to create new ones to also say to not show if they are member of a specific group.

In the permission schemes, there are many options such as permissions around attachments, logging work, making comments, linking, etc. All I was recommending is having a similar set of permissions for workflow transitions such that it is an easy thing to remove if you really want a project to be read-only.

[Nic Brough -Adaptavist-]

Mmm, but that's my point - each transition is unique, so you can't have a set of permissions for them. You wouldn't gain anything from it.

Although, I can see the point of a condition that does something like "and project matches these criteria".

To make a project fully read only, you add conditions like "users must be in role X" (universally for your use case), then to make the project read-only to a user, just make sure they aren't in X.

[Nic Brough -Adaptavist-]

But they do have specific permissions - you add conditions to the transitions.

It is not obvious for new admins, and adding confitions is something I continue to forget to do when creating workflows, even after years. But I can't think of another way to do it. You can't do it in a scheme because almost every workflow will be different, and transitions very different. The conditions you need to apply have a one-to-one relationship with the transitions so you can't really abstract them. The conditions you have available off-the-shelf include things like "user has permission X", which gives them an extra layer of flexibility that you couldn't do in a scheme.

I would argue for a default though - something like "automatically add a condition of must be in the role of user". At least that would quickly lead administrators there when someone says "I can can see it, but I can't do anything with it"

[Renjith Pillai]

That's probably the learning kalyann. To always have a project role or permission in all transitions' conditions.

[Nic Brough -Adaptavist-]

Yup. I suspect it's a hangover from when you couldn't change workflows, but I'd like to see it (gradually?) separated so that you've got actual permissions and a second block of "flags you can use in the workflow but don't have any effect outside it"

[Cameron Fowler]

The problem is that Jira calls out most of its built-in transitions in Permissions (Assign, Resolve, Close), so it appears that Permissions Scheme is the method for shutting down transitions when it is not.