We are currently testing this version out. Looks good so far! Thanks to everyone involved.

Thank you for the update.

Hi all,

We have rolled back the fix done to address the concerns expressed at JRA-31720 and from JIRA 6.2.2 onwards, the "Current Assignee" permission will work as used to work in the past, prior to the change done at JRA-31720 (JIRA 6.1.6)

Edit: Performance of this specific permission check will be back to pre-6.1.6 levels in JIRA 6.1.8 / JIRA 6.2.2 and later versions.

Hope the information helps.

Regards,

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

I think the reason it is affecting my user account so much is that we only have about 15 or so permission schemes, but we have two major permission schemes that have hundreds of projects in them. Which is by our design. The group "Group (jira-administrators)" has browse permissions. I am in that group. The reason why we have two large permission schemes is because there are users who have access to many projects. The other schemes we have are for projects who require extra security.

I see now why it is querying so often; but, I'm not sure there is anything we can do to work around this. If you have any ideas, let me know!

Thanks, Andrew

In the attached screenshot I can see that the SQL that is running is "SELECT COUNT(I.ID) FROM JIRAISSUE WHERE I.PROJECT = ? AND I.ASSIGNEE = ?"

So this means that somewhere we are still looking at a Permission that is granted to "CurrentAssignee" and we are asking whether the current user has that permission for a given project (not for an issue).
You say that you have removed the CurrentAssignee grant from "Browse Project" permission? So presumably you still use CurrentAssignee on certain other permissions?

Furthermore we can see that this SQL is being run 3 times in a row for each project ID it is looking at.
So perhaps there are 3 permissions using CurrentAssignee? Or perhaps that code is a bit stupid and checks the same permission 3 times?

Andrew, it would be helpful if you could check your settings and list which permissions are still using CurrentAssignee.

Mark,

I removed "CurrentAssignee" and "CurrentReporter" the other day as mentioned in the original ticket https://support.atlassian.com/browse/JSP-182394 and this ticket (in a testing environment). The gadgets loaded much faster, but still caused 20,000+ queries against the database, as you can see from the attached screenshot (also in that ticket). Currently in 6.1.2, only 8 to 15 queries are made to load a dashboard.

Could it be because I'm a JIRA System Administrator and have access to most projects? What is the workaround for that? There are other admins, and a larger amount of users that have access to multiple projects.

Andrew

Atlassian is aware of the pain that this performance regression is causing, and want to fix it ASAP.
However, we are trying to find a solution that also addresses the concerns with the previous behaviour that were raised in JRA-31720

In order to find the most suitable behaviour, we would like to get a better understanding of why customers are using "CurrentAssignee" and "CurrentReporter" to grant permission to "Browse Project".
It would be very helpful if some of you people watching this issue could explain the business reasons for setting up permissions this way.

Guys,

We have a pretty large instance of Jira at Motorola Mobility with 1M+ issues and need to upgrade to Jira 6.2+. However, at this point, without this issue being fixed, we are stuck.
Please atleast let us know what version of Jira this will be fixed. Looks like it didnt make it to 6.2. What point release of 6.2 will this be fixed?

Thank you,
Dev Govindaswamy

Just attached a screenshot to show that for each project, there is a SQL query to the database. Just think, with over 1,500 projects, that could take a while. But why does it add up to 20,000+? Should some of this be done using the indexes?

And the workaround doesn't work as expected. I have updated JSP-182394 with some information and a screenshot. Yes, loading gadgets are quicker when you remove "Assigned User" from the permission schemes, but it still creates 20,000+ database queries. See screenshot.