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.
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.
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.
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.
Hello! My name is Genevieve Blanch, and I'm the Marketing Manager at RefinedWiki, creators of apps to give teams the tools to customize Atlassian platforms. Currently, 44% of the tech team at Re...
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!
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