Restricting wrong Sprint selection

[Emil Naghiyev]

Hello,

Is it possible to restrict users from adding an issue to a Sprint of the another project?

For instance, an an issue belongs to Project A, but users add this issue to the sprint of Project B. 

[Jasmeet Kaur]

Hello @Emil Naghiyev 

Welcome to Atlassian Community 

In Jira Cloud, it is not possible to strictly restrict users from adding an issue from Project A to a sprint of Project B by default. This is because Jira allows sprints to span multiple projects if those projects are included in the same board filter. Here’s how it works and what you can do:

Why This Happens

• Sprints are board-based, not project-based: If a board’s filter includes multiple projects, any issue from those projects can be added to any sprint on that board.

• Permissions: To add an issue to a sprint, a user must have both the "Manage Sprints", "Schedule Issues" & "Edit issues" permissions in all projects included in the board filter. If they lack these permissions in a project, they cannot add issues from that project to a sprint. 

What You Can Do

1. Restrict Board Filters

• Configure board filters to only include issues from a single project. This ensures that only issues from that project can be added to sprints on that board 3.

• Example: Set the board filter to project = "Project A" for Project A’s board.

2. Tighten Permissions

• Limit "Manage Sprints" and "Schedule Issues" permissions to only those users who should manage sprints for each project. If a user does not have these permissions in Project B, they cannot add Project A’s issues to Project B’s sprints 1 2.

3.  Name Sprints Clearly

• Use clear naming conventions for sprints (e.g., "ProjectA Sprint 1") to reduce accidental cross-project assignments. 

Thank you!

[Marc - Devoteam]

Hi @Emil Naghiyev 

Make sure the users don't have access to the other project, or don't grant them Edit permission on the other project

It al depends on the permission scheme used on the project, based on role, group or user and if based on roles, what role the user has on a project.

Also an option is to use different permission schemes for a project.