Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Change acceptance workflow properties

I am working on a change management workflow where during the approval step we want to lock editing to either a group of CAB users or the assignee. That way people can't change the scope without the person doing the work or the authorisers knowing about it.

So far I have managed to block editing rights on that step only, and allow a group but I can't seem to find any combination that would the allow the assignee to edit as well if they are not in the group.

Does anyone know a workflow property and key that would target that?

3 answers

Hi @Alex Noble

To confirm, adding to Property Key:

  • jira.permission.edit.assignee
  • jira.permission.edit.group=XYZ

^ Doesn't work together? The properties should take into account either/or.

This would exempt the need for a "grant" vs "deny" permission - these would be granted whilst everyone else would be denied.

Ste

Hi Stephen,

 

This is what I have setup, so it works by stopping fields being edited, if a user is in the CAB group they can edit but when switching the assignee to a user not in the group they are unable to edit.

permissions.png

Please check if edit permission is restricted in your Permission Scheme.  If the assignee does not have edit issue permission in your permission scheme, then workflow property will not grant them permission

Hi @Alex Noble

So I did it slightly differently, I didn't include the "jira.issue.editable = false" part, which created too much restriction on the status.

By removing this, it did begin to work. I did find that the "Edit" button didn't always appear straight away though - but inline editing worked and that made the edit button appear.

Ste

@Nisha_Hajamohideen all Jira users have edit on my setup at the moment. 

 

@Stephen Wright _Elabor8_ so yours was the same just minus the first part, did you have to put in anything else to remove access for everyone else?

Hi @Alex Noble

No - because the permission properties are granting edit to specific users - so it limits it for everyone else. I found with the additional parameter it doesn't work as well.

Do bear in mind that my method only limits the "edit issues" permission only - so if you wanted to limit other permissions (eg. assign user) you'd need to add extra properties.

Something else to keep in mind is if approval is based on the status transitioning to another status, then you might want to limit who can activate the transition out of this status based on permissions from the transition properties.

Ste

Hello Alex,

 

Please review the steps given in

 https://confluence.atlassian.com/jirakb/how-to-limit-editing-permission-to-certain-groups-for-a-particular-issue-status-802171723.html?_ga=2.94553308.1123218146.1570447747-81822673.1565855644

this might have solution to your question.

For assignee you might have to add

jira.permission.edit.assignee = Granted

 

Thanks,

A more common way to do this is to limit editing entirely (via having a edit screen assigned to the scheme that has no fields in it), and use transition screens to to your editing. You create a transition screen with all the fields, and you have transitions that return to the same status that use that screen. You can then use conditions to limit who can execute the transitions.

 You can even use this to allow different users permissions to edit at different statuses. 

Its a little non-intuitive, in that the edit button on the issue is basically non-functional but it works well otherwise.

Interesting take doing it with the screens, I might just be over complicating things. The audit log of who makes changes is powerful enough that any scope creep or alterations are tracked from a change management perspective. I think I was keen once a request was submitted to avoid people sneaking in an edit and people not being aware. 

That's our major use case with it for our "RFC" request for change/change management use case. One the RFC is submitted and waiting for approval, no one can edit it because there is no transition out of waiting for approval with a transition screen.

Suggest an answer

Log in or Sign up to answer
TAGS
Community showcase
Published in Jira Software

How to create Jira issus from Excel file?

When to use CSV importer When managing your processes in Jira, there are many occasions where you need to create a lot of tasks. Creating them one by one will cost you a lot of time and effort and i...

4,346 views 22 31
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you