User has been given project admin role across all projects where stories originate. Still no luck in him being able to close a sprint.
Faced this problem today.
My user used for a board a complex filter which included Scriptrunner JQL functions and Portfolio hierarchies.
Resolved by adding an additional conditional to the JQL, which limited it to the projects I wanted, where my user had manage sprint rights.
So instead of the complex filter I used:
(Project = MyProject) AND (My complex filter JQL here)
Worked like a charm and fixed all "Manage Sprint" permissions.
I hoep this helps anybody
I tried this solution, but it was a bit cumbersome due to the number of projects our wider IT team uses. Weirdly though, this didn't actually solve the issue.
I had a look at the Atlassian support page Using Manage Sprints Permission for Advanced Cases and set up the Manage Sprint Role, which I added to all the permission schemes that we use. This didn't solve the issue by itself either, even when I added a brand new board with no fancy filters.
Eventually the only thing that fixed the issue for me was going and deleting all the existing boards for the project BEFORE creating a brand new one. I'm guessing there was some weirdness in one of those boards that was propagating somehow to new ones (we have some managers that like to create their own views using boards, not all of them are as adept as others).
It was a bit of a pain to set up the board from scratch again, but once it was set up (and all the Manage Sprints permissions were set up), there was no need to limit the JQL to the specific projects.
Hope this helps for someone who gets stuck with this issue......
I had an issue like this. The user had permissions to all projects involved, which was just two projects with a total of 8 issues.
I found via the Test View > By Sprint feature the Sprint was appearing on two boards. The JQL for both boards checked out fine when looking at the issues in the Issue Navigator.
However, one of the boards filters caused the Projects In Board to state The projects in this board cannot be listed because of the complexity of the board filter.
Because the second board wasn't needed we deleted it and then the problem with completing the sprint went away.
I am confident we could of fixed the JQL on the second board so Jira could identify the boards contained, and then we could of completed the sprint as well.
Can you explain how to get to the Test View > By Sprint feature? We have multiple team sprint boards that pull in issues from lots of different projects, and I am unable to get our scrum masters access to manage sprints even though every single permission scheme in use has the scrum master user group in both Project Admin and Manage Sprints permissions. I have resorted to adding them to the jira-administrators group in the meantime, while I work with atlassian support to resolve this problem. Atlassian support told me that because our boards use complex filters, Jira simply ignores the permissions and won't allow users to manage sprints (they said for performance reasons).
And here is what I really want to know: if the jira-administrator group can manage sprints, with no apparent degradation in performance, then WHY THE HELL can't they create a sprint-manager user group that gives everyone in that group the ability to manage sprints?? Obviously this has been an issue for quite a while; it's incredibly disturbing that it hasn't been resolved yet.
I had an issue like this in Cloud Jira even though the users were in a group that had Manage Sprints permission granted across all permission schemes. Many board filters are not limited to specific projects. (see Using Manage Sprints permission for advanced cases) After looking through the audit log, a new, private next-gen project was created recently. Once the project was deleted, non-admin users could manage sprints again.
In my instance, it was an issue because there were board filters that weren't specific to projects (for example, filtering on team). I would suggest seeing if a board filter for the board(s) that cannot close sprints can be modified to exclude that project - perhaps that would work? We deleted the project because it didn't have work in there yet, and we supplied the user with another way to keep track of work that wasn't a personal next-gen project.
Does the next-gen project need to have sprints enabled? We have a next-gen project not causing issues since sprints are not enabled.
I don't have an example to look at in my instance since the project was deleted, but maybe give the following a shot - documentation for managing sprints for next-gen projects seems to be a bit lacking.
In the project settings for the next-gen project, see if the people/group that need to manage the sprints can be added as a member to that project. If that doesn't work, trying as admin, if that isn't a risk.
I have multiple projects that use variations of the same base workflow. The variations depend on the requirements of the project or issue type. The variations mostly come in the form of new statuses ...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events