Using Manage Sprints permission for advanced cases
The 'Manage Sprints' permission (only available to Jira Software users) is a project permission that allows users to perform the following sprint-related actions:
- Creating sprints (current and future ones)
- Starting sprints (current and future ones)
- Completing sprints
- Reopening sprints
- Reordering future sprints
- Deleting future sprints
- Editing sprint information (sprint name, dates, goals)
- Moving the sprint footer
Caveats of the 'Manage Sprints' permission
With this permission, the board's filter query determines the projects 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 issues within the sprint.
When boards have complex filter queries
A filter query is considered complex when Jira Software can't determine which projects will be returned by the query. When this happens, Jira Software will require users to have the 'Manage Sprints' permission for all projects in the instance — essentially, you'll need to manually set users to have this permission for all projects.
To handle this better, consider using Jira project roles for the 'Manage Sprints' permission. While project roles are defined at the instance level, they are applied at the project level. Thus, project level permissions can be given to members of a project role, as well as groups, individual users, or through other means of designating a user. In essence, project roles enable you to associate users with particular functions for specific projects.
For example, you can consider doing the following:
- Create a new project role called Sprint Manager.
- In the corresponding permission scheme, assign the 'Manage Sprints' permission to the Sprint Manager project role.
- Associate the permission scheme with the corresponding projects in your instance.
- Add the appropriate users to the Sprint Manager project role.
Completing these steps will make sure that the appropriate users have the Sprint Manager project role in the corresponding projects — and since the 'Manage Sprints' permission is assigned to the Sprint Manager project 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 project in the instance. | Add the project clause into the queries. This will reduce the number of projects Jira Software will check permissions on. |
project = TIS OR issuetype = Bug | ||
project = TIS OR (issuetype = Bug AND assignee = someone) | ||
(project = TIS OR assignee = A) AND
| Jira Software 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 projects 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 projects. |
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, and - your
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 issues 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 Software checks if you have the 'Manage Sprints' permission for the projects in the origin PMO board.
- If you have permissions, the sprint will be closed. If Sprint 3 has any incomplete issues, Jira Software will offer destination options, allowing you to move the incomplete issue to either the Backlog or a future sprint of the TIS board, e.g. Sprint 4.
- If you choose to move the incomplete issue to Sprint 4, the issue is moved to Sprint 4 of the TIS board.
- If Sprint 4 also exists in the PMO board, then the incomplete issue will appear in Sprint 4 of the PMO board.
However, if Sprint 4 doesn't exist in the PMO board, the incomplete issue will be moved to the Backlog of the PMO board.