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 Egan]

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.

[Cyril Egan · Accepted solution]

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:

1. Issue (Example: PA-1) exists on project A and is in the active sprint.
2. User 2 clones PA-1 creating PA-2 (which now becomes part of the active sprint).
3. User 2 moves the new issues PA-2 to project B and PA-2 now becomes PB-1.
4. Remember User 1 does not have access to Project B.
5. 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."
6. 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.
7. 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:

1. Give User 1 project admin rights to project B and get them to complete the sprint.
2. 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.

[Nabil Sayegh]

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

[Błażej O_]

Sure thing, thanks ;)

[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?

[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 Egan]

Thanks Shaun - I'll give it a go.

[Jason S]

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

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

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

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

[Girish Krishnamurthy]

Error provide project names Need JQL query for this scenario Thanks Jeff

[Jeff M]

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.

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