How can I prevent issues from being assigned to sprints not related to their assigned project?

Due to people assigning issues to incorrect sprints accidentally, velocity charts are getting poor data.  This is especially true for our organizations large JIRA projects which need to have their issues only in their project related sprints but have a lot of people able to edit the sprint value.  I would like to prevent this from happening by using ScriptRunner to physically limit the sprints that the issues can pick but I do not know how to implement the script for two reasons.

1. I would like to avoid the Behaviors plugin (part of ScriptRunner) because that limits where the Sprint can be changed to the Issue Edit Screen.

2. Listeners won't work because the change is fully edited before a listener is fired.

Also to note, the "Edit Issues" permission is trimmed down as much as possible for the projects of concern. 

To my current knowledge, this leaves Javascript as my only option and implement it through a script fragment.  Am I missing something or is there any other way I could implement this?  


3 answers

1 vote
Tarun Sapra Community Champion May 22, 2017

You can do couple of things as well -

1) Look into "Manage sprint" permissions.

2) Since you mention "project related sprints" , - Since Scrum boards are visible only to people having access to the underlying Filters, thus you can have groups specific to filters , i.e. share the filters only with the groups and once you do that then the board will also be visible to the speific group and in this way you can make sure that using these 3 combinations - Edit issue, manage sprints and filter share permissions you can restrict unneccesary access to the sprint value.

Also, please remove the "sprint" field from the"Edit" screen just to make sure that this field is only visible on the "view screen" and is getting updated only via backlog management of the scrum boards i.e. through drag and drop and not manually editing the field.

I completely forgot about about the Edit screen option, that is definitely something to look into.  So if it is removed from the Edit Screen you can still edit the sprint in the backlog view of a scrum board?

To your first and second comment though, I don't think it would work well for "my" case.  The projects I want to implement this for involves around 100 users on a project.  So even though we split people up with groups (has edit issue permission and who doesn't) it is still inevitable that people will screw up and add an issue to a 'bad' sprint.  Especially with a high profile project, I need a more surefire way to make sure bad data doesn't get generated on the project.  That is why I was looking to more of a coding method.

This was meant to go under "Tarun Sapra" response

You can remove the "sprint" field from the Edit Screen and also finetune- manage sprint permissions thus it will narrow down things to selected group of people, who can do things in the backlog view of things.

You have mentioned 

" it is still inevitable that people will screw up and add an issue to a 'bad' sprint. "

Why is this happening in the first place? Only Scrum Master or Product Owner should have the rights to add issues in the sprints and backlog in the scrum board.

For our larger projects, on average these sprints hold around 1800 story points (12,000 - 13,000 hours) worth of work.  Being able to effectively manage that kind of work requires the help of more than just a few people.  Also, even though we have developed very specific sprint naming conventions, mistakes still happens when there are hundreds of sprints in the environment that all have similar naming.  The combination of amount of work and number of sprints especially on teams that are a little bit new to JIRA is not a good combo.  I can look a little more into manage sprint permissions but from what I have seen, that isn't going to be 'our' answer because we have the Edit Issue permission as limited as possible for the larger teams.  I need something more like a validator that still allows for JIRA to not limit our users in ways to edit the field, but still guide them incase a mistake is made.

If you're going to avoid Behaviours, and using a Listener to retroactively fix the issue isn't an option, then I would agree that rolling your own javascript through a Custom Web Resource is probably the main way you could approach the issue in ScriptRunner.

Behaviours is designed to do exactly this sort of thing (provide client-side guidance and validation), but if disabling inline edit on the view screen isn't an option, then unfortunately it won't work for this case. 

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Mar 13, 2019 in Marketplace Apps

Marketplace Spotlight: Marketing apps for Confluence to keep your teams working on the same page


280 views 0 7
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you