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; } } }

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

Karie Kelly1

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.

Accepted answers

Nic Brough -Adaptavist-

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

All comments

Nic Brough -Adaptavist-

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

Karie Kelly1

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 Kelly1

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.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

jira-cloud