chris.volker1, we will be looking to improve the UI and messaging to avoid these problems occurring and to improve permissions for sprint management. Please see GHS-5035.

Kind regards,
Martin
JIRA Agile

We are currently using JIRA 6.3.7 and JIRA Agile. Since our upgrade we have noted the common Sprint field became much more user friendly giving users a drop-down to choose from instead of forcing users to enter a Sprint ID. However when users attempt to close the sprint users next receive the message:

"To Update this sprint you must have Project Administrator permissions for all of the following projects............."

While this is a nice feature, it has creates a problem with Agile Boards. If a Sprint is listed in any project, it stops people from starting or stopping a sprint unless that person is an admin of the project. This poses a problem because users were are linking Change Management type issues to their sprints, requiring us to give developers ADMIN rights to our Change Management project. Our workaround was to remove the Sprint field from the screens so that no one can use it. Essentially, making the Sprint field more user friendly caused some unintended security permission issues to other projects. I am curious if there is any another work around, or if a patch is in the works.

I agree with improving the error message the user gets in this particular scenario. More useful information (particularly the troublesome ticket ids) in the error message would help!

This issue would be somewhat mitigated if users had the ability to give more fine-grained control around sprint permissions. Please see the linked issue for details on that.

For this issue specifically, we will consider improving the messaging to users around why they are not able to complete the sprint.

Regards,
JIRA Agile team

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.

Has anyone noticed that when you move a ticket from one project to another, the "foreign sprint" shows up on the target project's boards?

We just noticed this and had a terrible outcome. User cleared out all the sprint values associated with the project the tickets came from, and managed to close out the sprint of another team's project!

This person had no admin rights or board admin to the source project but was able to close out the sprint!

Folks - this is becoming critical. When you have many, many projects, issues get moved around and you are making it to where I have to give everyone responsible for managing sprints administrative access to all projects which is a HUGE security issue. Why does Atlassian not take security issues, seriously. Every 2 weeks, I spend time trying to figure out why a product owner cannot close a sprint. This is absolutely ridiculous that Atlassian has not addressed this long-standing issue, when it is a security gap and is very difficult to determine root cause (what issue was moved from where to where) and open up administrative privileges.

Also experience this issue in Agile 6.3.12. Atlassian please address this long standing issue.

Interesting, so neither project has any scrum/kanban boards? If so, then my work-around might only work for the cloned issue GHS-9030.

@Phillip - Glad that works for you. However, it doesn't seem relevant to us. These are issues in projects that have no scrum boards or even kanban boards. They are issues that were logged in, as an example, a customer support area. Once determined valid, we had to move into the appropriate product project. In these cases, we had to make the entire product management team an administrator of the customer support area. A big security issue and concern when I have so many that are admins of so many projects, when they shouldn't be.

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

Hi folks,

Has anyone found a workaround to remove the value of the Sprint field upon issue move?

Thanks,
Nicholas Muldoon

Those workarounds are not appropriate when just moving an issue from one project to another when it has nothing to do with a sprint. This occurs even when it is moved and then added to a sprint at a later date.

I need a way to clean up all issues to remove this meta data that the issue originated in another project as I have no way of going through hundreds of thousands of issues to find out which ones, in each board, are causing the problem. The longer you delay resolution, the larger the cleanup process becomes.

This same problem occurs when cloning boards - there is another issue logged. There appears to be some kind of issue meta data that is not getting cleared and it causes significant confusion and an admin nightmare.

I don't believe that this is a minor issue at all because it is a security issue since the only workaround is to give admin permissions to individuals that should not have such permissions. This is a significant security issue when I have to give all product owners and any other board owner, admin permissions to areas that they should not have that capability as we move issues around all the time. We have one location for support issues to go to and then they move to the appropriate product space; or, when issues are created in one project and have to be cloned or moved to a different project for some reason.

Not addressing security issues as a critical priority is a non starter for us when working with Atlassian products, especially if Atlassian doesn't take them seriously.

We've noticed the same error resulting in another scenario: Board A contains Project A. Board B contains a subset of data from Project A (component 1 say) and Project B. If the user does not have project administrator rights on both Project A and Project B they are unable to complete a sprint in Board A and receive the above mentioned error

"Error To update this sprint you must have Project Administrator permissions for all of the following projects: Project A, Project B.".

I propose changing this from a "story" issue type to a "bug" and moving it up in priority. We have many instances of boards that cross projects and intend to ramp up use of such board types, but will not be able to do so if this bug isn't resolved soon.