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. 

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

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

[Nancy Desai]

Okay, your solution was close but here's the problem...I thought BA was a group. Turns out, it's a role. So, while I could do a denied value based on role, the recommendation is to deny by default, and then add permission to allow editing. So, the example would be: jira.permission.edit.projectrole.1  with a property value of: 10002. The property value is the roleID which you find by hovering over usage in the roles section. 

[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

[Nancy Desai]

This did not work. 

[John Funk]

Can you be more specific?