Hey when is this going to be fixed? the above change has been very detrimental to my organization. this is causing us to have to create hundreds of duplicate filters and dashboards to support individual projects. This is another example of Atlassian making changes without viewing how their users are utilizing the software. 

https://community.developer.atlassian.com/t/jql-queries-containing-issuekey-or-issue-will-have-the-error-messages-and-response-code-changed/48242 - this "fix" is actually not a fix! users could already not see the full key if they didn't have access to the other project. so the fix was not thought through, and not understood what the ramifications would be and closed out for comments less than a month after creation and change. while there are request to have it fixed that are much older. Please Jira FIX this! please remove the change!

With the changes in JQL queries containing issuekey or issue will have the error messages and response code changed ("JQL queries with issuekey or issue will be returning different error messages and status codes in case of nonexisting project or lack of permissions.") this may now happen when the query includes an issue key, as well as a project key, that the user does not have permission to access.

Dylan, when can we expect this but to be fixed?

this was working up till may now I'm getting this problem. this is an active issue. 

Due to an extended period of inactivity and low interest this bug has been auto-closed. If you’re still experiencing this issue, please comment and we’ll re-open to triage.

Cheers,

Dylan - Service Enablement @ Atlassian

I also commented in JRA-40245 but wanted to comment here as well since these are related issues...

We have an agile board with multiple "customers" (represented by projects) and we want to share access to the board (specifically the backlog view) with those users who have "BROWSE" access to ONE of several projects.. HOWEVER, we can't do this because the users must currently have "BROWSE" permission on ALL of the projects returned from the shared filter (which drives the issues in the board). Today, when the users who are restricted to view a single project login, they see the board with NO ISSUES because of the limitation of the filter.

Ideally, as described above, if I have filter criteria which includes a project for which a user has BROWSE permission, they will see those results which are related to the specific project issues they are permitted to BROWSE.

This would allow us as a consulting company to share our sprint boards and our backlog views with our customers, without creating separate boards and running sprints for each customer separately.

I would argue that making this change would be critically valuable when it comes to running a collaborative sprint with mixed permissions.

Hi all,

Just a quick status update.

In order to be able to tackle this bug, it would be necessary to implement the improvement described at JRA-40245.

Regards,

Oswaldo Hernández.
JIRA Bugmaster.
[Atlassian].

It is definitely not what I would expect to happen. If a user doesn't have permission to view a project, then the gadget results should simply not include that data. Not error out

I've seen a couple of issues like this one where someone from Atlassian puts an "occurrence factor" on the issue that estimates the prevalence of the problem. I'm curious about how Atlassian arrives at the percentage given. I know they probably have good data on the cloud-based instances, but I wonder how much insight they have into server-based instances.

In our case: when a project is over, we assign it a permission scheme that makes it readonly for everyone. After a time, we make the project hidden altogether. In addition, our security team makes us pretty diligent about removing people's access to projects when they move on to other assignments. It seems like there are probably plenty of companies like mine who choose to run server-based instances behind firewalls for a reason. Security is one of those reasons, so I would think there are other server-based instances whose security policies are similar to ours. I only have one vote on this issue, but we have 5000+ users in our instance.

Hi chris.milam,

Thanks for expressing your interest in this fix, unfortunately this is not currently in the short-term backlog for an upcoming JIRA maintenance release.

Having said that, this is still an issue we would like to fix when we are working trough other bugs in the Gadgets area. Please watch this issue as I will update it as soon as new information becomes available.

In the meanwhile, as a workaround, users should still be able to see the results of the shared filter via the issue navigator.

We are sorry that this is causing pain for your users, and I hope the additional information helps.

Regards,

Oswaldo Hernández.
JIRA Bugmaster.
[Atlassian].

Has there been any progress on this issue? It is negatively affecting our organization.