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?
Hi @Alex Noble
To confirm, adding to Property Key:
^ 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.
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.
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.
Please review the steps given in
this might have solution to your question.
For assignee you might have to add
jira.permission.edit.assignee = Granted
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.
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...
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