Automation to undo ranking change

[Matt Cavanagh]

I have a scenario where I need undo any changes to ranking for tickets, as only certain people in the business need to be able to rank.

I've explored using "Schedule Issues" permission, however that also disables the ability to assign issues to sprints (a huge annoyance that they're not split into separate permissions!) making it too restrictive, we want more than 1 person to be able to assign tickets to sprints.

Therefore, I'm attempting to explore using an automation (I've got Automation for JIRA and ScriptRunner installed) to undo any changes to ranking by unauthorised users.

In my research, I've attempted to get any kind of value for ranks from the issue, but they appear to be in a format I can't adjust. I also can't use Automation for JIRA to check if the field "rank" has changed as it's not an option.

Anyone got any ideas?

[Andy Heinzer]

It might be possible to use a script/automation in order to undo changes to the rank field on issues, but let me be clear that I actively discourage this approach.  I can see a number of potential pitfalls trying to do this.  

Some background: Ranking is a feature of Jira Software. Every issue in Jira Software has a rank value, even if they are not in a Software type project.  But that rank value is not displayed to the end user, it really isn't designed to be.  I'm not sure how you would do this monitoring of permission checks as to which users are allowed to change this, plus I'm not sure what overhead this would have on your system.    Also Jira can rebalance the rank field on the back end.  This happens when you have too many values change in a short interval and there no longer exists sufficient balance between issues (balance here meaning the lexorank value space between rank values).  When this happens, all the rank values can change on the backend, but the individual issues in Jira don't change their rank in relation to each other.   That detail is important to know if you try to go ahead with automating a change like this.

Instead, I have a different approach that might help here.   Instead of granting all your users access to the board/filter you are currently using, I suggest you try to create a new filter that has the exact same JQL as your existing filter, but that is not ordering by Rank field. 

Say your current filter is something like this:

project=xyz order by rank asc

Change the filter to be just

project=xyz

(You could order by some other field aside from a rank field too).

Save that filter.  Then create a new board that uses this new filter and share the filter with your users that can add issues to the sprint, but that you don't want to change rank.

When you have a filter that is not ordered by rank used on a board, users of that board cannot change the order in which issues will be ranked.  But they can still add issues to a sprint, if they have permissions.  The downside to this approach is that these users can't actually see what the rank will be for the issues.  They won't be able to know which is higher and which is lower, only that issues are in that sprint.  They could also still create their own personal filter, and their own private board which could be ordered by rank, so if they have the manage sprint permission for this project, they could potentially get around this.   But this might be a viable alternative for your use case.

[Matt Cavanagh]

We wish to order by the universal rank, not by project, not by a custom field ranking. JIRA doesn't offer the ability to split the permissions out, which there's been a lot of votes to implement here: https://jira.atlassian.com/browse/JSWSERVER-6887

The issue is that anyone with the permission to rank are also the only ones who can schedule issues into sprints, which needs splitting. Therefore in my situation it's an all or nothing solution, which in itself isn't a solution, hence why I'm trying to figure out alternative methods.

There appears to be none :(