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

Lock down editing of a US for a specific group once the US reaches a point in the workflow?

Nancy Desai

I have a group (let's call them BAs) that constantly edit US once they hit the In Development status of our workflow. It obviously creates a moving target and my team does not know what to delivery or they have to constantly make changes to their code because of these moving requirements.

I want to stop the BAs from editing the US in any shape or form once the US hits In Development in the workflow. This lockdown should then apply for all future US statuses in the rest of the workflow.

I know it's possible because JIRA was originally set this way when I first started but our JIRA admin changed it on my recommendation and now I realize I was an idiot to trust that group. The original JIRA admin is no longer employed at my company.

Accepted answers

All comments

John Funk

Hi Nancy - Welcome to the Atlassian Community!

You are not going to be able to lock down a single field by status by group. You could use issue level security to lock the entire issue from a group once it hits a particular status, but not just a field.

Nancy Desai

I'm good with that. But do you know how I can do it? Is it a setting in workflows?

John Funk

You can learn more about that here:

https://confluence.atlassian.com/adminjiracloud/configuring-issue-level-security-776636711.html

Nic Brough -Adaptavist-

Um, slight problem with issue security - it will hide the story completely! Not only will your BAs not be able to edit the issues, they won't be able to even see what the story is.

I would do this with workflow properties instead. You can add a property to a status that can change the permissions while the issue is in that status. jira.permission.edit.projectrole=10010 for example, will stop anyone who isn't in the developer role from editing the issue (assuming the id of the developer role is 10010)

Note that the properties apply during outgoing transitions as well - if you do something like block comments on a status, then when you have a transition screen on an outgoing transition, the comment during transition will be blocked too.

Nancy Desai

That is perfect! thank you for the information. I'll look into the string and project roles to get it identified in the workflows.

Nancy Desai

Okay, I'm back. I went into workflow properties, I went to my story status of In UAT. I added this property key: jira.permission.edit.denied.group=BA and property value of true. Here's the problem: no one can edit once I do this. I checked the project users membership and I'm only an administrator and part of the delivery manager group. So why can't I edit? Am I using the wrong property key? I've googled it and can't find a good answer.

Nancy Desai

This did not work.

Nic Brough -Adaptavist-

> jira.permission.edit.denied.group=BA and property value of true

Sorry, I was not clear here. The = separates the property from the value of the property when I'm writing this stuff. So

jira.permission.edit.denied.group=BA

would actually be a property of jira.permission.edit.denied.group with a value of BA

However, I also have a nagging doubt that what you actually want here is

Property: jira.permission.edit.group value: penguins

Which should limit the editing to only members of the group penguins...

Welcome!

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

Quick Links

Find more posts tagged with

cloud

jira-software

jira-software-cloud