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 * There are issues linked using the Jira link operation between project X and project Y in case this is important. * The default Jira workflow is being used in both project spaces on all issues. The user clicking the "Complete Sprint" button: * Is the owner of the board and the filter * Is an administrator on Project X * Is not an administrator on Project Y * Has rights other than administrator rights on Project Y so can browse, create etc. 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.

nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Getting following error completing a sprint in GH6 - To Update this sprint you must have Project Administrator permissions for all of the following projects

Cyril Egan1

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

There are issues linked using the Jira link operation between project X and project Y in case this is important.
The default Jira workflow is being used in both project spaces on all issues.

The user clicking the "Complete Sprint" button:

Is the owner of the board and the filter
Is an administrator on Project X
Is not an administrator on Project Y
Has rights other than administrator rights on Project Y so can browse, create etc.

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.

Accepted answers

Cyril Egan1

I had another occurrence of this today so I took more time to investigate it. The scenario is as follows:

One GH scrum board called "Project A" with filter "project = Project A order by Rank Asc"
Two project spaces. Project A and Project B.
Two users:
- User 1 is Project A admin on project A but does not have access to project B.
- User 2 is a user that had access to both project A and project B. They can clone and move issues in project A. They have a minimum of create and browse permission on project B.

Steps:

Issue (Example: PA-1) exists on project A and is in the active sprint.
User 2 clones PA-1 creating PA-2 (which now becomes part of the active sprint).
User 2 moves the new issues PA-2 to project B and PA-2 now becomes PB-1.
Remember User 1 does not have access to Project B.
User 1 then tries to complete sprint on scrum board but will receive error message similar to "To update this sprint you must have Project Administrator permissions for all of the following projects: 10052, Project A."
The ID number is the ID number of the project to which the cloned issue was moved and Jira won't show you its project name I suppose for security reasons.
The poor project admin can't release the sprint because of this error and they can't see it on their board even if they modified the query so they can't remove it from the sprint.

Workarounds:

Give User 1 project admin rights to project B and get them to complete the sprint.
Put in a customised workflow for all issues to clear out the sprint upon the create transition. However this may not be desirable because the user cloning may want the new issue to be in the sprint. If we clear it out then they would have to remember to add it to the sprint from the backlog.

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.

All comments

sclowes

Hi Cyril,

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()".

Thanks,
Shaun

Cyril Egan1

Thanks Shaun - I'll give it a go.

Jason S2

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."

Cyril Egan1

I had another occurrence of this today so I took more time to investigate it. The scenario is as follows:

One GH scrum board called "Project A" with filter "project = Project A order by Rank Asc"
Two project spaces. Project A and Project B.
Two users:
- User 1 is Project A admin on project A but does not have access to project B.
- User 2 is a user that had access to both project A and project B. They can clone and move issues in project A. They have a minimum of create and browse permission on project B.

Steps:

Issue (Example: PA-1) exists on project A and is in the active sprint.
User 2 clones PA-1 creating PA-2 (which now becomes part of the active sprint).
User 2 moves the new issues PA-2 to project B and PA-2 now becomes PB-1.
Remember User 1 does not have access to Project B.
User 1 then tries to complete sprint on scrum board but will receive error message similar to "To update this sprint you must have Project Administrator permissions for all of the following projects: 10052, Project A."
The ID number is the ID number of the project to which the cloned issue was moved and Jira won't show you its project name I suppose for security reasons.
The poor project admin can't release the sprint because of this error and they can't see it on their board even if they modified the query so they can't remove it from the sprint.

Workarounds:

Give User 1 project admin rights to project B and get them to complete the sprint.
Put in a customised workflow for all issues to clear out the sprint upon the create transition. However this may not be desirable because the user cloning may want the new issue to be in the sprint. If we clear it out then they would have to remember to add it to the sprint from the backlog.

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.

Błażej O_

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.

Nabil Sayegh

@Blazej If you'd turn your comment into an answer I'd upvote it.

Błażej O_

Sure thing, thanks

Jeff M

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.

ElizabethH

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?

Elvar Bjarki Böðvarsson

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.

Girish Krishnamurthy

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

Jeff M

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.

Ruchi Tandon

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.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

jira-software