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

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?

Accepted answers

All comments

Ste Wright

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

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,

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

Ste Wright

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

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.

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