How to use cross team filters without permission problems

[Isaac_nl]

Hi,

I am observing that if a search filter references a project that the current user does not have access to, the filter won't work at all and show an error.

For example we have 3 projects PROJECTA, PROJECTB, PROJECTC and I create a filter for a board to see all security issues:

labels in ('security') and project in (PROJECTA, PROJECTB, PROJECTC)

 This works OK if you have permission to all projects. But I want to keep share this filter so that users from PROJECTA or B or C can also use it to see the overview of security issues. Some users have access to A and B, some to B and C, or only B, etc. All combinations are possible. 

Problems is that if a user doesn't have access to one project, for example PROJECTA, the whole filter will stop working for that user.

- A value with id '10031' does not exist for the field 'project'.

What are you people using as a workaround alternative? And is there a JIRA Server feature request to fix this as this is making life a lot harder. The only thing I can think of is grant all users access to all projects. Or create one filter per project. Both don't scale if you have tens or hundreds or projects.

[John Funk]

Hi Isaac,

One option might be to grant Browse Projects permission to all users for all 3 projects. Then add an Issue Security Level to each project uses a Project role. Then you can apply the same Security Scheme to all issues, but it will control access by being in a particular role in that project. 

[Isaac_nl]

Thanks, but that doesn't really scale either.

[John Funk]

Why wouldn't that scale? 

[Isaac_nl]

I don't want users to have browse permission on 100s of projects and then having to remind everyone they need to set a security level on each issue to prevent other people from seeing it.

[John Funk]

No, you create a generic Security Scheme that is used across all projects and set the Security Level as a default so that it is automatically applied to every created card. 

[Isaac_nl]

I don't think it was intented to work like this, so wouldn't to invest in this method and then atlassian maybe changing things at some point. I have also seen that default values, for example for resolution, are not set when using the API. 

Also it would allow anyone in the project to remove the security level, exposing the issue to broadly.

[John Funk]

Well, in my opinion, that's exactly what it is intended to do - control access to an issue. I believe that is your intent unless I am missing something. 

And not sure what the API or resolution has to do with your question at all if you want to clarify that part. If not, not biggie. 

And, no, who can set or remove the security level is controlled by the permission scheme as well. Simply only allow Administrators to set the security level. 

You can do what you want - the solution will solve your problem and answers your question. You asked for a work around which is what this is. Not sure how else to help you. 

[Isaac_nl]

We have issues being created via the API via external tools. Most tools only cover the basic JIRA fields so relying on any other fields such as security level can lead to problems.

I don't want to limit who can change the security level, our intention is that developers can decide to make issues "internal only" and I don't want to take that permission away.

[John Funk]

Those are additional requirements that were not mentioned in your original question. You can simply add the Developer project role to the permission scheme for who can set the security level. 

Also, I am not sure that the security level would interfere with the creation of the issue using the API as it is added as a part of the creation process. 

[Trudy Claspill]

I am not aware of any work around for this to display Search Results in JIRA. It is fundamental to the design of JIRA that a user must have the Browse Projects permission for all the projects referenced in a filter in order to see the results of the filter. If the user does not have permissions to any one or more of the referenced projects, then no results will display.

If it is not an issue to let the user see the results that would come from the project to which they do not have permissions, then you could set up a Subscription to the filter and email the results to the user. 

I have not tried to search for a change request on this topic in Atlassian's backlog.