User with Administer Project, Manage Sprints and board admin permissions is unable to manage sprints on a board

Still need help?

The Atlassian Community is here for you.

Ask the community

Platform Notice: Cloud, Server, and Data Center - This article applies equally to all platforms.

Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.

*Except Fisheye and Crucible

Problem

When attempting to manage sprints with actions such as Move, Start, Create, or Sprint displaying incorrectly, this is likely due to being unable to manage sprint permissions. Examples of this are

  1. You try to Move a Sprint up or down on a board, Close a Sprint, or  Completing a Sprint, you get an error message: To update this sprint you must have Project Administrator permissions for all of the following projects: (list)
  2. The Start Sprint button is disabled and the following error appears on the Rapid Board when hovering on the Start Sprint link:  Project Administrator permissions are required to manage this sprint
  3. A sprint shows up on a board in which it wasn't created.
  4. Making a change to a sprint in one board affects a sprint in another board.
  5. A sprint shows up on a board after an issue has been moved to it from another board.

Cause

Sprint data aren't dependent on a specific board or project. It is, therefore, possible for a sprint to be displayed on more than one board. It is still one entity, though, and changes made to it in one board will be reflected in the other too. It can happen that the same sprint is used in two boards erroneously, e.g. if the sprint naming convention is the same for all boards, and the incorrect sprint with the same name was linked to an issue. Furthermore, if an issue was modified or moved and as a result, is displayed in a new board, the sprints that it was originally assigned to will be shown in that new board too. In such cases, it would be unexpected that the same sprint is displayed in two boards, even though it is technically correct. 

 A sprint will be displayed on a board under one of the two conditions:

  • it was created in that board (this can be checked in the database, in the RAPID_ VIEW_ID column in the  "AO_60DB71_SPRINT"  table);
  • issues included on the board are associated with the sprint

It is recommended that sprint names indicate the project or board name, in order to avoid confusion. A related behavior to this is tracked in the Feature Suggestion:  JSW-10805 - Getting issue details... STATUS  Having said that, a Sprint is still associated with its  Original board in the database for checking of permissions. See:  Using Manage Sprints permission for advanced cases

Diagnosis

If you cannot perform some Sprint operation due to this permissions error then you have issues from multiple projects in your sprint. There are two causes for this.

  1. Your board filter includes issues from a project where you are not able to edit issues.
  2. Issues in restricted projects are assigned to your sprint.

Check your original board filter

  1. Get the original board associated to your sprint. The board ID will be returned in the RAPID_VIEW_ID column of the query: 

    SELECT * FROM "AO_60DB71_SPRINT" WHERE "NAME"='Sprint Name';
  2. Configure your board and ensure you're on the General and filter page: <BASE_URL>/secure/RapidView.jspa?rapidView=<board_id>&tab=filter
  3. Locate the field Projects in board.
    1. Does it show a select few projects? Or does it indicate that too many projects are involved?
  4. If there are too many projects listed, it means that the filter must be modified to only include the projects you want.
  5. Edit the filter and ensure that the JQL include the proper project
    1. For example, if your project key is "ASDF" add this JQL to your filter: Project = ASDF AND

If any of the issues are from a project where you do not have edit permission then your board filter is the problem.

Navigate to the board's configuration page General and filter check that the board has Ranking enable

  1. Look for the field named "Ranking"
  2. Does it exist? If not, there's a button to "Add Rank".

Check for issues in restricted projects

  1. Go to Issues > Search for issues
  2. Enter JQL to find issues in your sprint from other projects.
    • For example, if your project key is "ASDF" and your sprint is "ASDF Alpha" use this JQL:  A Sprint = "ASDF Alpha" and Project != ASDF
  3. Execute the search and examine the results.


If any of the issues found are from a project where you do not have edit permission then issues in restricted projects is the problem.

This can result from normal user activity such as moving an issue, cloning an issue, or editing the Sprint field from Issue Details.

To list all the Projects associated with the Sprint, the following SQL query can be used

select distinct p.pname from jiraissue ji, project p, customfieldvalue cfv, customfield cf where ji.project = p.id and ji.id = cfv.issue and cfv.customfield = cf.id and cf.cfname = 'Sprint' and cfv.stringvalue = (select CAST(s."ID" as TEXT) from "AO_60DB71_SPRINT" s where s."NAME" = '<SprintName>');


Workaround

There few ways to solve the problem here depending on the scenario that you are facing:

For Issues in restricted projects assigned to the sprint

  • Rename your sprints to avoid users choosing the wrong one
  • Remove the Sprint from issues in the other projects (requires issue edit permissions)
  • Use the JIRA Automation Plugin to change the Sprint when an issue is moved.

For Board Filter Issues

  • Update your original board filter to exclude issues from those projects.
  • If you don't need your original board any more, delete it. This will remove the reference of your sprint from it. 

Rename your sprints

You can mitigate the problem of users selecting the wrong sprint from Issue Details. Alert the board owners in your organization about this problem and ask them to name their sprints in ways that clearly identify them. For example, in a project "ASDF", sprints could be named "ASDF Alpha", "ASDF Beta", etc.

Remove the Sprint from issues in the other projects

  1. Contact someone with edit permissions for the projects noted in the error message. Alternatively, ask for edit permissions in the project(s) so you can do the cleanup yourself.
  2. Given a project "ASDF" and a sprint named "ASDF Alpha", this person would...
  3. Go to Issues > Find Issues.
  4. Select the Advanced search mode.

  5. Enter JQL to search for issues in the "ASDF-Alpha" sprint that are not in the "ASDF" project: Sprint = "ASDF-Alpha" and Project != ASDF

  6. Select Tools > Bulk Change

  7. Select all the issues and click Next.

  8. Select the Edit Issues option and click Next.

  9. Check the box next to "Change Sprint" and leave the field value blank.

  10. Follow the prompts to complete the Bulk Change operation.

  11. When this is done you should be able to close your sprint.


Use the JIRA Automation Plugin to change the sprint when an issue is moved

Platform notice: Server and Data Center only. This article only applies to Atlassian products on the Server and Data Center platforms.

Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.

*Except Fisheye and Crucible

Unsupported

This workaround uses a free Atlassian Labs add-on and therefore Atlassian does not provide direct support for it. This is offered in the spirit of helping to find a solution but your teams must decide if this approach is appropriate and sustainable.

Use an issue filter to restrict this automation to a test project so you can test the result thoroughly before applying it globally.

The JIRA Automation Plugin can edit field values when they are moved or cloned. It does not have the ability to unset a field so for this workaround we will "park" issues in a sprint created for this purpose to allow the original sprint to be closed.

  1. Install the JIRA Automation Plugin.
  2. Create a "placeholder" sprint. When issues are moved or cloned they will be added to this sprint to replace their current one. Give it a name such as "Limbo - Do Not Use".
  3. Find the sprint ID  for this new Sprint and save it for later.
  4. Go to  Administration > Add-ons > Manage add-ons > Automation
  5. Click "+ Add Rule" and fill out the form:
    • Give it a name such as "Remove sprint on move".
    • For "Actor" use a JIRA Administrator account that can edit issues in all projects.
    • Check the box for "Enable rule once created"
  6. In the next screen:
    • For "Event Trigger" select "Issue Event Trigger"
    • For "Issue Event" select "Issue Moved"
  7. Type "Sprint" in the "JQL expression" field. Note the custom field ID, "cf[#####]". You will need this custom field ID in the next step.
  8. Complete the "JQL expression" field to exclude issues that have no sprint from processing:

    Sprint IS NOT NULL

    NOTE: This is also where you can restrict the automation to a test project to be sure the rule is working the way you want before applying it to other projects. Example: Sprint IS NOT NULL AND Project = "My Testing Project"

  9. On the next screen...

    • For "Choose action" select "Edit Issue Action".
    • For "Edit Fields 
    • For "Edit Fields" enter "customfield_FIELD_ID=SPRINT_ID" where FIELD_ID is the custom field ID you identified previously and SPRINT_ID is the ID of your "parking" sprint. Example: 

      customfield_10005=6
  10. Click "+Add Action" and configure another action to notify the person that moved the issue about the change.

    • For "Choose Action" select "Comment Issue Action"
    • Enter a comment that will be added to the issue. Example: "This issue was moved to a new project and the sprint has been changed. This was done to ensure the sprint owner will be able to close it. Please review the Sprint field and change it to the correct value as appropriate."
  11. Click "Next" and then "Save".

  12. Check to be sure the automation rule is Enabled.

Now when an issue is moved to another project the sprint will be changed to your "parking" sprint. Moved issues will no longer block people from closing sprints.

This workaround does not prevent the problem for Cloned issues because JIRA does not provide an event listener for cloning. You may be able to solve this by configuring automation for the "Issue Created" event so long as Sprint is not a field in your create screens. 

This workaround does not prevent users from choosing an incorrect sprint from Issue Details. Please see "Rename your sprints" for a suggestion on this.


DescriptionWhen attempting to manage sprints with actions such as Move, Start, Create, or Sprint displaying incorrectly, this is likely due to being unable to manage sprint permissions.
ProductJira
PlatformServer, Cloud
Last modified on Aug 1, 2023

Was this helpful?

Yes
No
Provide feedback about this article
Powered by Confluence and Scroll Viewport.