Use manage sprints permission for advanced cases
The 'Manage Sprints' permission (only available to Jira users) is a space permission that allows users to perform the following sprint-related actions:
Creating sprints
Starting sprints
Completing sprints
Reopening sprints
Reordering future sprints
Deleting future sprints
Editing sprint information (sprint name and dates)
Moving the sprint footer
Caveats of the 'Manage Sprints' permission
With this permission, the board's filter query determines the spaces that users need to have permission on. Also, permissions are now checked against the filter query of the board from which the sprint originates, not just against the work items within the sprint.
When boards have complex filter queries
A filter query is considered complex when Jira can’t identify which spaces the query will return. In these cases, you must have the 'Manage Sprints' permission for all spaces in the instance before you can create new sprints. To manage an existing sprint, you must also have this permission for all the spaces containing work items in the sprint.
To handle this better, consider using Jira space roles for the 'Manage Sprints' permission. While space roles are defined at the instance level, they are applied at the space level. Thus, space level permissions can be given to members of a space role, as well as groups, individual users, or through other means of designating a user. In essence, space roles enable you to associate users with particular functions for specific spaces.
For example, you can consider doing the following:
Create a new space role called Sprint Manager.
In the corresponding permission scheme, assign the 'Manage Sprints' permission to the Sprint Manager space role.
Associate the permission scheme with the corresponding spaces in your instance.
Add the appropriate users to the Sprint Manager space role.
Completing these steps will make sure that the appropriate users have the Sprint Manager space role in the corresponding spaces — and since the 'Manage Sprints' permission is assigned to the Sprint Manager space role, then these users can perform sprint-related actions.
The following table lists some examples of complex filter queries, and suggestions on simplifying such queries.
Complex filter query | Why the query is complex | How to simplify the query |
|---|---|---|
assignee = someone | These queries return global context results because the results could potentially come from any space in the instance. | Add the space clause into the queries. This will reduce the number of spaces Jira will check permissions on. |
project = TIS OR issuetype = Bug | ||
| ||
| Jira will evaluate this query as:
The red parts of the query won't return any results, which makes the query complex. Since the query returns undefined results, the 'Manage Sprints' permission will then be required for all spaces in the instance. | Rewrite the query as: (project = TIS AND assignee = B)OR(project = PMO AND assignee = B)
With this query, users will be required to have the 'Manage Sprints' permission on only two spaces. |
In summary, we recommend that queries contain OR clauses in which AND clauses can be sub-clauses, and not the other way around.
Simply put, make sure:
your
ORclauses are outside the brackets, andyour
ANDclauses sub-clauses are inside the brackets.
Recommended query format: <clause> OR (<clause> AND <clause>) OR <clause> OR (<clause> AND <clause>)
Complex query format: <clause> AND (<clause> OR <clause>) AND (<clause> OR <clause>)
When boards contain sprints from other boards
With the 'Manage Sprints' permission, permissions are now checked against the filter query of the origin board — the board from which the sprint is created — not just against the work items within the sprint.
Depending on the filter query being used, your board might display sprints from other boards. For example, you have the TIS board and it's displaying Sprint 3, which was created in another board — the PMO board. In this case, the PMO board is the origin board of Sprint 3.
If you're in the TIS board and you're closing Sprint 3, the following items are checked:
Jira checks if you have the 'Manage Sprints' permission for the spaces in the origin PMO board.
If you have permissions, the sprint will be closed. If Sprint 3 has any incomplete work items, Jira will offer destination options, allowing you to move the incomplete work item to either the Backlog or a future sprint of the TIS board, e.g. Sprint 4.
If you choose to move the incomplete work item to Sprint 4, the work item is moved to Sprint 4 of the TIS board.
If Sprint 4 also exists in the PMO board, then the incomplete work item will appear in Sprint 4 of the PMO board.
However, if Sprint 4 doesn't exist in the PMO board, the incomplete work item will be moved to the Backlog of the PMO board.
Was this helpful?