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

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.

To add to DLDuncan's response...

I understand that your process deals with votes and number of users experiencing this issue; however, in our case, this is more complicated. We have 1,536 projects in one instance of JIRA. Those projects are owned by our clients, which range from the Federal Government, State and Local, and Companies. When they use JIRA, they want gadgets and filters to load within a reasonable amount of time, not minutes.

At this time we are on version 6.1.2 with no speed issues, but we are experiencing more issues that have been resolved in newer releases; but we cannot until this bug is fixed. We have been a client of yours since 2009 (and even further back to 2006 at BearingPoint).
What must be done to get this on the developer’s radar? Just imagine how our users see JIRA performing across the globe on our one instance of JIRA. I receive complaints from clients every day.

Please refer to our original ticket at https://support.atlassian.com/browse/JSP-182394

Thank you,

Andrew Moulton, JIRA Administrator/Developer
amoulton@deloitte.com

This issue is keeping us from being able to upgrade to latest stable version and also affecting our ability to upgrade clients who are running jira, as well as recommend jira to new clients who are looking for a tool to provide the services of jira.

Thanks for the update amoulton, we will keep updated on this issue as soon we have more information about this.

Regards,

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

Thank you for your response. This ticket was actually created from our issue we reported a while back, which is why we went back to 6.1.2.

Hi amoulton,

Is this fixed in JIRA 6.2?

This particular issue is not fixed in JIRA 6.2 yet, but we do plan to work on this soon.

However, you might be running into another performance issue different from the one tracked here. As this issue is only a problem for JIRA 6.1.6 and later.

Consequently, could you please create a support ticket at https://support.atlassian.com? That way we can provide you with support specific to your circumstances and our support engineers might be able to workaround the issues you face during upgrade so that your are able to access the fixes in newer versions that you are looking for.

The credentials should be the same as for this site (https://jira.atlassian.com).

Regards,

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

This is a big issue for us as our instance of JIRA is unusable on any version greater than 6.1.3. We have other bugs that are fixed in later versions, but we have to deal with the old version of 6.1.2. Is this fixed in JIRA 6.2?