I have a user that is associated with a group that has been granted the Manage Sprints permission. This user can create, edit, delete & start sprints but they can't complete a sprint. I've confirmed that all issues in their sprint are from a single project and that project's permission scheme has granted their group the Manage Sprints permission.
FYI - I had the same problem, and what I came to as a workaround was to rewrite the filter to explicitly set an outer bound limit on the projects that could be covered. i.e.
Project in (ABC, DEF, GHI, HIJ) AND ( originalfilter )
That seems to allow JIRA to determine the list of possible projects. Obviously this wouldn't work in all cases of queries that you really want to be across system, but it's an easy workaround for the case where you just need to make "some user's query" work for them in board.
Thank you Nathan!
After days of searching around (and not being overwhelmingly impressed by the available documentation), I found your tip and it worked brilliantly.
Run the original query first to see the results (and hopefully see the list of all the project keys - as some might be there you weren't expecting).
To anyone else reading, as far as I know, the person viewing the board has to have Manage Sprint permissions to all the issues encompassed by the query the board is based on. Without something like the "project in" limiter in the query, that would mean the viewer would probably need that permission in all the projects in your JIRA instance.
I also believe that if the query involves Service Desk projects, the viewer also needs to be a Service Desk agent to get the board to work (even if they have the Manage Sprint permission).
Other possible problems I've found - I'd guess the user might have to be in a JIRA Software licencee (rather than Core) in JIRA 7+?
Also, if you have multiple permission schemes make sure that the project role you THINK has the Manage Sprints permission has the permission for all the permission schemes involved.
Anyway, thanks again Nathan!
What version are you working with? The reason I ask is that Atlassian had to revert the deployment of Manage Sprints and return to the previous permissions of Schedule/Administer but retained the permission in the system even though it was not applied.
"On 9 December 2015, due to a number of issues raised relating to new Manage Sprints permission, we removed the functionality from JIRA Software Cloud temporarily, as blogged here. After resolving these issues and performing additional quality checks, we are now re-releasing the improved Manage Sprints permission on the week starting 25 January 2016." Ref:https://confluence.atlassian.com/jirasoftwarecloud/blog/2016/01/reintroducing-sprint-management-in-jira-software-cloud
So it is worth checking what version is installed and when did you have this problem.
Thanks Phill for trying to help me out. We are on version, 7.2.0-OD-03-010. We are currently experiencing this issue with only one of our users. I've granted this users group the Administer Projects permission but they are still experiencing this issue. It just seems weird that they can create, edit, delete & start sprints but can't complete them.
We have this problem too now, after upgrading from 7.1.0 to 7.1.2. Our scrum masters have to come to someone with full JIRA admin rights, which is very unsatisfactory.
I stumbled on this answers.Atlassian page and have raised a support issue, as it seems we can't fix this by ourselves.
We solved our problem. We have boards which span multiple projects, so you'd see tickets like FOO-1234 and BAR-4567.
Although our scrum masters had the requisite perms in each, when we looked at the board settings, under "General and filter", JIRA said it couldn't identify which projects appeared on the board and printed "The projects in this board cannot be listed because of the complexity of the board filter".
The boards used to work and still do, just the manage sprint button is broken. We think that Atlassian changed the precedence of operators AND or OR.
We added additional brackets into the board filter expressions to make them completely explicit and not reply on operator precedence.
And then on the General and filter page, the list of projects appears with their icons.
Our problem was also a board configuration issue. The filter that drove the board had something like the following:
Project in (ABC, DEF) OR Scrum Team = "Team 1"
As you can see we have boards that span multiple projects too. Majority of our projects use the exact same permission scheme. This permission scheme grants our Scrum Master group the manage sprints permission. But we do have one permission scheme that doesn't grant this permission that is used on just a few random projects.
So when I ran the filter that drove the board all of the issues were in projects that used the permission scheme that granted the manage sprints to our Scrum Master group. But because of the "OR" in the filter there is a possibility that some issues may be in the other projects that don't use the permission scheme that grants manage sprints to our Scrum Master group.
So the solution was to update the permission scheme for these few random projects to grant the manage sprints permission to the Scrum Master group or correct the filter where there isn't a possibility to pull issues from those projects.
So the lesson learned for me was that it doesn't matter what the filter is "actually" pulling in but instead it's what the filter could "possibly" pull in.
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
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot