We had a situation where a project administrator was trying to complete a sprint in Greenhopper 6.0.5 today.
When they clicked the "Complete Sprint" button on a scrum board they got the following error message...
"To Update this sprint you must have Project Administrator permissions for all of the following projects. Project X, Project Y"
The board is only configured for Project X. The filter for the board is:
project = "X" and fixVersion not in (Deleted_Items,Draft_Items) ORDER BY Rank ASC
The user clicking the "Complete Sprint" button:
Granting the user admin rights to Project Y gets rid of the error message and allows them to proceed.
I don't see any issues from Project Y on the board.
I've searched answers.atlassian etc but can't see a simiar problem reporter.
I had another occurrence of this today so I took more time to investigate it. The scenario is as follows:
I would suggest that Atlassian look at this anomoly and see if maybe they could put in a 'keep in current sprint' check box at clone time or something similar. Should default to off.
Cyril's answer captures the error and scenario I'm seeing. Basically, I get this error when trying to close a sprint that contains a ticket that was cloned from one project to another, where I only have admin permissions on the latter project.
Do we know if this bug has been fixed yet?
The Sprint most likely includes issues from Project Y that are not visible (i.e. the board is filtering them so they're not shown but they are still in the sprint). You can test this by running a search with JQL like "project = Y and Sprint in openSprints()".
Interestingly, we're seeing some similar behavior even when we've isolated issues to a single project and sprint but are receiving the same error. Granting Admin rights to other projects where issues are linked did not suppress the error. Of note is that our message seems to refer to multiple projects, the first of which is simply a number (none of our project keys are named thusly) : "To update this sprint you must have Project Administrator permissions for all of the following projects: 10052, MyProject."
Thanks for such detailed breakdown of the problem! It helped me a lot to resolve similar problem in our instance.
Just one word for anybody who'll experience it too. If the error gives you project names rather than id's it means you at least have rights to view the problematic issue. You can simply add the excess project to the filter on your scrum board. The problematic issue should appear in the sprint, so now you can simply remove it from the sprint.
The "10052" situation was resolved. Because only a few people had browse to that project - not including JIRA Admins - the error only generated the ID when it came up from time to time and running queries for it showed nothing since we didn't have browse access to the issues. JIRA made it seem like that number didn't exist in the system. A database search on the projects table for that ID equated the project name and I granted myself browse permissions so I could run queries to find the link between the hidden project and the one with the sprint. Using the JQL project = projectnamethatwentwithid10052 and Sprint in openSprints() I found 4 issues, two of which had the sprint name that was currently throwing the error.
I cleared out the sprint field in the offending issues and that freed up the board.
That was the best and quickest way to debug and solve this for me. Another issue that everyone seems to forget is that when you are viewing an sprint in the agile board you are viewing it through the lense created by the agile board filter. If the filter shows you only issues from one project you will not see the issues on the same sprint that belong to another project. What is also in a way strange is that when you click view these issues in a issue view that the search created is not sprint = somesprint but a list of issues, project-1,project2 and so on. How this is handled means you also miss seeing the actual problem there. I can understand that you should be able to assign sprints to issues on a different project but how the error is handled and presented is seriously broken.
User is trying to change sprint date for sprint # 1427 and project X but he is getting error " To Update this sprint you must have Project Administrator permissions for all of the following projects X,Y" Need JQL query for this scenario Tried query project = Y and Sprint in openSprints() not working
Does the error give the project names or is one just the ID #? If just the ID # can the JIRA admins run the query "project = projectID#"? If so they'll get a list of all the issues in the project and therefore the project name will be exposed in the Project field and in the Issue IDs themselves. An admin would then need to run the JQL for "project = Y and Sprint in openSprints()" because results are security trimmed - if you don't have permission to the project issues JQL won't show results for issues in the project that match the query. If admins can't query based on ID # then the project admin excluded JIRA Admins from the project permissions and we'll have to get you to the project name in a roundabout way.
opensprints() probably doesn't work because the sprint hasn't started? Maybe just project = Y AND sprint = 1427 Quotes would be needed if referring to the sprint by name but not ID. In my particular situation this was a problem because someone cloned an issue from project x that was in a sprint, to project y. It can also happen if an issue in a sprint is moved from x to y. The non-technical approach could be to check with people in Project Y to see if they cloned/moved anything from Project X. As suggested in one of the other solutions you can add Project Y to your board's filter and the offending issues should show on the board in the sprint and you can find it that way, assuming the person viewing the board has browse permissions in project Y. They should if they see the project's name in the error rather than just the project ID.
Here is a knowledge base article based on the problem here : https://confluence.atlassian.com/display/JIRAKB/Not+able+to+make+changes+to+sprint+due+to+missing+project+administrator+permissions+on+unrelated+projects. This article should describe the problem as well as the resolution.
Atlassian ranks project attributes as the third most important factor impacting performance in the category of data. It’s not surprising, since project attributes are precisely the rules used to ma...
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