After running into this issue I feel that the problem is not a or transition problem it is a error handling problem and in some ways a interface problem.

When you are viewing a 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.

That JIRA includes the sprint information when you move the issue, or even clone the issue to a different project is the correct behavior. When you do either of those tasks you are supposed to get all the information with it. Clearing the sprint field is not the right way to handle this.

My very easy recommendation to resolve this.

1. When you get the error message you should be able to see all the issues that are stopping you from closing the issue.
2. When you view the Sprint in the Agile board the filter on that board should not apply but instead it should filter on the Sprint ID. At least present a toggle to enable or disable the Agile board filter.

This issue is eroding the already shaky confidence our users have for Jira and the Agile Plugin.

ABSTRACT
User attempts to close a Sprint,but receives an insufficient Project Administrator permissions error message for one or more Projects
SYMPTOM / ERROR MESSAGE
Error: To update this sprint you must have Project Administrator permissions for all of the following projects <lists JIRA Projects>
CAUSE
The board is only configured for some of the Projects which have Issues associated with the Sprint in question.
Agile (GH) Bug: GHS-6850: Sprint can't be closed if you move an issue to another project
NOTE: This can also occur if an Issue is Cloned then moved to another Project.

+1 at LinkedIn we are having major issues with this. Would love to hear an update on when this will be fixed.

Thanks,
Chris

This is almost a daily occurrence. Would love a fix as education doesn't seem to stem the tide of teams who find an issue has gone elsewhere.

Thanks,
Nick

We just found another way this can happen. The recent update of JIRA Agile adds the sprint field on all edit screens.

If you have sprints that are named the same across boards, a user can accidentally set an issue to another team's sprint while editing, which would trigger this problem.

This mistake is harder to make on the Plan board.

Can we please get a response from Atlassian as to when the focus will be on fixing these type of critical (this is not a major) issues and those related to security and permissioning? These issues resulting in major disruptions and inabilities to actually use the product and security concerns should be of the highest priority for Atlassian to resolve.

Hitting this on a weekly basis with teams as they triage their backlogs.

Hi,
Yes, this sounds accurate. I also believe that when the user tries to complete the sprint for Project B, they are told they cannot because they do not have "Administer Projects" permission on Project A. The problem is the moved ticket inherits the previous project's sprint information. The work around is to either remove that sprint number from doing a bulk change on the new ticket or to give administer projects permission rights to both projects for both users. The ladder work around is not good cause you don't have people to have administer project rights on a project they aren't part of. The first work around works better but is a pain. We were able to systematically resolve this issue using a Post Function to purge the contents of the field Sprint for cloning but couldn't figure out a way to wipe this field out during a move issue to another project operation. If anyone knows how to do this, then the severity of this ticket would go down.

Thanks.
Pat

Hi all,

For clarity, could I get some more information about the specifics of the problem people are experiencing? This is my assumption of what is happening; please correct me if I am wrong.

1. A board exists with issues from PROJECT A
2. A sprint is started on that board with some issues from PROJECT A
3. An issue in the sprint is moved to PROJECT B
4. The user who manages sprints for PROJECT A has "Administer Projects" permission on PROJECT A, but not PROJECT B
   • When that user tries to complete the sprint for PROJECT A, they are told they cannot because they do not have "Administer Projects" permission on PROJECT B.

Does that sound accurate? Are there any other ways you are encountering the problem of "Sprint can't be closed if you move an issue to another project"? I'm particularly interested to hear if the problem still persists even if the user has sufficient permissions for both projects concerned.

Thanks,

This is a problem for us as well. Would be nice to be able to close a sprint without having to complete the above workaround. Thanks.

Hi all, I'd like to pitch for this to not be "minor". It cost me and my team at Twitter two hours to deal with and it will certainly come up again.

Another month and I count five more teams that experienced this. Any chance there is a solution to this slated for early next year?

Hi tkotecki,

Is there any chance this will get pulled into a release this side of Christmas? We've seen a number of teams get bitten by this over the past few months and would love to have a permanent solution and avoid the workaround above.

Thanks Tom, have a top day,
Nick

yes, @Philip - as mentioned on the linked issue, if we just move any issue from one project to another, we run into this. Most of the issues come from projects that have no associated scrum board. Some don't have kanban boards either. Seems like the issue is maintaining meta data about where is was created that is causing the issue.

However, due to the security of having alot of admins for every project, I do not believe it is a minor issue. Security concerns should be considered higher priorities.

Here's my comment from GHS-6850:

Here's a work-around I found:

1. Move the issue back to the original project
2. Drag-and-drop the issue from the sprint into the backlog
3. Move the issue back to where it came from

any updates regarding this issue?

Hi,
can this be addressed soon? We don't allow people to change the sprint value in JIRA so the work around doesn't work for us. In order to push this through, a sysadmin will need to complete people's sprints which isn't a good practice.

regards,
Pat