Close Sprint permission logic breaks with query that defines projects by category

[Celina Kincaid]

Board filter is dynamic based on category.  This prevents us from having to manually add a project each time.  

The board settings doesn't show an error about projects, it in fact knows we currently have 50 projects returned.

All 50 projects use the same permission scheme.

User has the manage sprints permission in that permission scheme.

They still can't close the sprint.

No archived projects exist.

Double and Triple checked that all projects in that category have that scheme.

[Trudy Claspill]

Hello @Celina Kincaid 

You must explicitly declare the in-scope projects in the JQL filter. You can't use criteria to select the projects (i.e. using the project category.)

Otherwise Jira will assume that any and all projects may have issues that are within the scope of the board, and the users must then have Manage Sprint permissions for all projects on the Jira instance. 

This has been discussed in at least a few previous community posts:

https://community.atlassian.com/t5/Jira-questions/Using-manage-sprints-permission/qaq-p/2221414

https://community.atlassian.com/t5/Jira-Service-Management/Manage-Sprint-permissions/qaq-p/2810356

[Celina Kincaid]

Yes, I'm aware of all that.  Did you see where I said EVERY project in that category shares the same permission scheme that DOES allow that access? 

[Trudy Claspill]

Hello @Celina Kincaid 

Yes, I did. 

Did you notice that I said that the project scope in the filter must be declared explicitly, not by criteria?

You must declare the project scope as project in (project 1, project 2, project 3). You cannot use selection criteria such as category = "Production Support"

If you do not explicitly declare the projects in scope then Jira will consider all projects to potentially contain issues that may match the filter. It doesn't matter if the actual results of the filter are issues from projects where you do have the permissions. The potential for an issue to be in any project will require that you have the appropriate permission in every project on your Jira instance.

I think if you try changing your filter from

project in ("Quavo Support Development") OR (category = "Production Support" AND "Development Team[Dropdown]" IN ("Support Development") )

//tp///

project in ("Quavo Support Development") OR (project in (<comma separated list of all projects in the Production Support project category>) AND "Development Team[Dropdown]" IN ("Support Development") )

...you will then find that your users with the Manage Sprint permission in all the explicitly specified projects will be able to close the sprints.

[Celina Kincaid]

Not trying to kill the messenger here but something still seems off.  I'm clearly telling it what projects to use.... 

We have another team that uses this query and they don't have to be a global admin to close sprints....

category = "Cloud Services" AND "Development Team[Dropdown]" != "Support Development" ORDER BY priority DESC

[Trudy Claspill]

TL;DR

I have tested this repeatedly over the years. I am accurately stating how Jira evaluates the filter. I recommend that you actually test it yourself by explicitly naming the projects that have the specified Project Category value.

The longer version

Using category = "Cloud Services" tells Jira to look at every project in the instance and find the ones that have that Project Category set to that value.

That is no different than saying status=Done which would require Jira to look in every project at every issue to assess if the issue status matches the criteria.

It doesn't matter in either case that the results come from a subset of projects to which you have the required permissions. When evaluating a filter that does not explicitly declare the project scope by naming each project in scope, Jira will decide that all projects are in scope and require you to have the Manage Sprint permission in all projects.

It is simply not possible to use criteria based on Project Category to select the Projects for your scrum board filter and be able to manage sprints in that board without the Manage Sprint permission in every project.

[Trudy Claspill]

Hello @Celina Kincaid 

I'm checking back to see if you have any remaining questions on this topic. Have you done additional testing to validate my statements?

If you have determined that my statements are accurate in explaining the functionality you are experiencing, please consider clicking the Accept Answer button to mark your Question as Solved.

If you have additional questions on this topic, please don't hesitate to ask them.

[Celina Kincaid]

This mysteriously started working this week.  I have asked other our admins and so far no one has touched anything.  Our board filter still references projects by category so I'm waiting on one more admin to confirm they didn't do anything.  If not, then Atlassian finally learned to accept project category as a 'defined' group of projects.  

[Varsha Joshi]

Hi @Celina Kincaid 

Is it possible to share your board filter, obfuscating anything proprietary?

[Celina Kincaid]

project in ("Quavo Support Development") OR (category = "Production Support" AND "Development Team[Dropdown]" IN ("Support Development") )

this was the first query that didn't work

so I broke it down to find the culprit and this is the problem

(category = "Production Support" AND "Development Team[Dropdown]" IN ("Support Development") )