Change acceptance workflow properties

[Alex Noble]

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?

[Andrew Laden]

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.

[Alex Noble]

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. 

[Andrew Laden]

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.

[Nisha Hajamohideen]

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,

[Stephen Wright _Elabor8_]

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

[Alex Noble]

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.

[Nisha Hajamohideen]

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

[Stephen Wright _Elabor8_]

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

[Alex Noble]

@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?

[Stephen Wright _Elabor8_]

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