Jira Agile issue ranking permissions

Question

It seems there is difference in permissions required for issue ranking on Scrum and Kanban board.

Permissions required for issue ranking according to our research:
Kanban Board: Schedule Issues AND Edit Issues
Scrum Board: Only Edit Issues

For what we know this difference is not mentioned in Atlassian documentation (for example here).

It is very important to us, as we intend to manage ranking permissions dynamically by granting (or revoking) Edit issues permission through workflow properties. It should be possible according to documentation, however it is not specifically stated anywhere.

But it does not work. Kanban board does not respect "jira.permission.edit.group" workflow property denying editing for specific status in issue workflow - OR granting only Schedule issues permission is enough to enable ranking on the board . So permissions required for ranking on Kanban board are not Schedule Issues AND Edit Issues, but Schedule Issues OR Edit Issues.

Example: All users in group jira-rankers have granted both Edit issues and Schedule issues permissions. After setting "jira.permission.edit.group = jira-administrators" workflow property for workflow status "In progress" we expected that issues with status "In progress" couldn't be ranked by users not in "jira-administrators" group from this moment on. But this expectation was not correct, these issues were still rankable.

Does it mean there is a mistake in documentation or is it a bug?

Andy Heinzer · Answer

Thanks for clarifying.  You are correct that there appears to be a permission inconsistency here.  I see that you also created another support case for this issue.  There the agent created a new bug ticket for this issue in

https://jira.atlassian.com/browse/JSWSERVER-19790

I believe this bug is derived from a previous one that was closed prematurely in

https://jira.atlassian.com/browse/JSWSERVER-10639

I would recommend watching these bug tickets for updates on this issue.

Thanks for reporting it.

Andy

Juraj Drahoš · Answer

According to documentation, both Scrum and Kanban boards definitely should have same permissions required for issue ranking (for example here)

But there seems to be a mistake in description of problem I provided originally. I performed further testing, here are conclusions:

Environment:
Jira Software Server v7.9.2
Scrum Board
Kanban Board with backlog ("Scrumban")

Scenarios (all of them performed in board backlog):

1. User has granted both edit issues and schedule issues permissions
   - Issues on Scrum Board ARE rankable through drag and drop (CORRECT)
   - Issues on Kanban Board ARE rankable through drag and drop (CORRECT)

2. User has granted only schedule issues permission   
   - Issues on Scrum Board ARE NOT rankable through drag and drop (CORRECT)    
   - Issues on Kanban Board ARE rankable through drag and drop (INCORRECT)

3. User has granted only edit issues permission
   - Issues on Scrum Board ARE NOT rankable through drag and drop (CORRECT)    
   - Issues on Kanban Board ARE NOT rankable through drag and drop (CORRECT)

4. User has granted edit issues neither edit issues or schedule issues permissions    
   - Issues on Scrum Board ARE NOT rankable through drag and drop (CORRECT)    
   - Issues on Kanban Board ARE NOT rankable through drag and drop (CORRECT)

So to correct the provided description of problem:

Permissions required for issue ranking according to our research:
Kanban Board: Only Schedule Issues
Scrum Board: Schedule Issues AND Edit Issues

Rest of description remains unchanged.

That fits to the fact that issues on Kanban board are still rankable despite the workflow property denying editing in specified workflow status.

You are right, ranking can be succesfully managed also by "schedule issue denied" workflow status property and not only by "edit denied" property, but still I think it is more confusing this way than using "edit denied" property.

But the fact that Atlassian documentation is at least not clear or worse maybe wrong in describing board ranking permissions remains.

Andy Heinzer · Answer

So I tried to recreate this in my own environment.  I found that even on a scrum board, in order to rank issues, users need to have both the edit and schedule permissions in that project.   So that is the first thing to make sure we're clear on here.  Regardless of whether this is scrum or kanban, I believe the user will need both permissions to rank issues in the project.

But if we turn to your workflow property steps, this could be a viable way for you to limit when some users can change the rank of an issue based on the status of the issue.   But I agree that Atlassian hasn't really documented these properties to the fullest.  I suspect this could be because some of the functionality you can achieve in workflow properties could possibly change in a future revision.  There is a note about this in our documentation called Workflow properties:

Please Note: Not everything on this page is recommended!

* We do not recommend using all of these types of workflow properties as we cannot guarantee that some data and operations (e.g. bulk operations) will not be broken. Hence, use these types of workflow properties at your own risk!

That said, I did try this out myself, and I found I could still restrict this permission via a workflow property in my Jira 7.12.3 version.   I will try to share my steps with you here.  Since I think you are primarily concerned with the ranking aspect here, I used a workflow property specifically to restrict the schedule property.  You could use the edit, but this restricts all kinds of edit to the issues in that state.

For my workflow in question, I edited the workflow, in the 'In Progress' state, I clicked the 'View properties' link for that state, and in that property I added a

Property Key

jira.permission.scheduleissue.group

Property Value

jira-administrators

Note: After you add this, you do need to publish that workflow again in order for this setting to take effect.

Second Note:  Make sure you're adding this property to the status properties and not the transition properties.  For this to work, the property has to be set on the status, not the transition itself.  These can look very similar and get confusing sometimes.

In my setup, for this specific project, only users in the jira-administrators group can actually change the rank/scheduling of any issue in the status of 'In progress'.  Other users of that board/project that are not in that group can't change the schedule.  When they try to do this on the board, they get an error such as

However in my setup, that user does have the edit/schedule permissions in that project, and they can do that for issues in that project, but not the 'In Progress' issues because of the workflow property.

For reference sake, other users have attempted to document many of the workflow properties available in Jira.  I would recommend checking out J-tricks tutorial on this topic: J-Tricks: Permissions based on Workflow Status