Uploaded image for project: 'Jira Software Data Center'
  1. Jira Software Data Center
  2. JSWSERVER-6850

Moving issue from project in rapid board to another project results in inability to close or start sprint for non admin

      NOTE: This bug report is for JIRA Software Server. Using JIRA Software Cloud? See the corresponding bug report.

      A project admin user moves an issue from Project A to Project B when still associated with Rapid Board A. The issue is added to the Project B rapid board.

      Later a user in either Project A or Project B attempt to close their respective sprints in Project A or Project B rapid board. They are each greeted with an error:

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

      It would be better if the move did not result in a requirement for an admin in both projects to close the sprint.

      Also reported here in Confluence Docs:
      https://confluence.atlassian.com/display/GH/Ending+a+Sprint?focusedCommentId=330795683#comment-330795683

      This is really confusing to users because you can't remove the sprint from the moved issue unless that issue exists in some other board.

      UPDATE: This also affects the ability to start sprint.

      Workarounds

      • Do a Bulk Edit on the moved issues to remove the value for the "Sprint" from those issues;
        OR
      • Add the "Sprint" field to the Edit screens associated with the issue types for that project you moved issues to and edit the issues and remove the value for the "Sprint" field;

            [JSWSERVER-6850] Moving issue from project in rapid board to another project results in inability to close or start sprint for non admin

            Thanks for watching, voting and commenting on this issue.

            Unfortunately, this is not actually a bug and so I will be closing this issue. It is expected behaviour based on the way the product currently works today but as many of you have noted it is not actual expected or desired behaviour for many cases. We will be looking to solve this problem with a combination of improved sprint management and better information and notifications in product.

            A proposal for sprint management improvements can be seen on https://jira.atlassian.com/browse/GHS-5035 and I would recommend following that issue for progress and/or to add your comments.

            Kind regards,
            Martin
            JIRA Agile

            Martin (Inactive) added a comment - Thanks for watching, voting and commenting on this issue. Unfortunately, this is not actually a bug and so I will be closing this issue. It is expected behaviour based on the way the product currently works today but as many of you have noted it is not actual expected or desired behaviour for many cases. We will be looking to solve this problem with a combination of improved sprint management and better information and notifications in product. A proposal for sprint management improvements can be seen on https://jira.atlassian.com/browse/GHS-5035 and I would recommend following that issue for progress and/or to add your comments. Kind regards, Martin JIRA Agile

            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

            Martin (Inactive) added a comment - 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.

            Chris Volker added a comment - 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!

            Abdullah Akbar added a comment - 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

            Michael Tokar added a comment - 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.

            Elvar Bjarki Böðvarsson added a comment - 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.

            Paul Jarman added a comment - 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.

            David Yu added a comment -

            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!

            David Yu added a comment - 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.

            Karie Kelly added a comment - 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.

            Darren Campbell added a comment - Also experience this issue in Agile 6.3.12. Atlassian please address this long standing issue.

              Unassigned Unassigned
              e8a02d4d348a Warren Warren
              Affected customers:
              57 This affects my team
              Watchers:
              62 Start watching this issue

                Created:
                Updated:
                Resolved: