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.
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).
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!
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.
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.
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.
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"
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"
In the past, Portfolio for Jira required a high degree of detail–foresight that was unrealistic for many businesses to have–in order to produce a reliable long-term roadmap. We're tur...
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!
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