Ah I see thanks.

This has only been resolved for the server versions, not the cloud version :/

Why is this marked RESOLVED when it is still a problem? If ORDER BY is defined its for a reason.

Sorting also appears to be broken for the Filter Results Gadget when using 3 sort criteria (total 27 characters). Please update the title of this bug to read: "Sorting of Filter Results Gadget doesn't Work when Using More Than 2 'Order By' criteria".

As Sorting is core functionality of a dashboard, I request upgrading the priority to Critical to prevent the starvation on this issue that has been occurring since 2010.

Awaiting fix too and still can not believe how project leads, who strongly use dashboards, can work without this feature, because the overview feature of the dashboard is totally wrecked and you always have to consult the original filter. So as a consequence, the filter gadget is useless in this case. And I am still wondering, why having more than 3 sorting criteria is really so uncommon.

For me "ORDER BY duedate ASC, priority DESC, type ASC, status DESC, updated DESC" totally makes sense, at least the first four.

Thank you in advance!

Still an issue in v7.1. Can't wait until this bug gets fixed! Thanks

Yes harald.raetscher, the bug report is clear at the moment. As you mention, you can always refer back to the original filter in the issue navigator to obtain correctly sorted results as a workaround in the meantime.

Regards,

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

This sounds good From my perspective this is no big deal. The filter already selects the issues to be display and normally has some order criteria. And a gadget on top shall only provide some kind of view, to narrow the information. So I think it makes no sense to allow the user to select from all the fields, because only the fields from the filter should be available. As a consequence, there is no problem with the sorting, because it will be obtained from the filter itself.

Am I thinking in the wrong direction?

Hi harald.raetscher,

We determine priority strictly based on the information available at Priority Levels.

To further clarify, the priority field in this project is used to measure an issue's severity rather than its scheduling priority. Having said this, this is an issue that I have been monitoring closely for a while and given we have freed up some space in our backlog and the number of votes and interest on this issue, I have just added it to my team's short-mid term backlog.

Please do watch the issue for further information, we will update its status as soon as more information is available.

Regards,

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

Why is this a minor issue, especially due to the fact that it is 5 years old? All "manager" dashboards with the purpose of monitoring pipelines do not show the right order. You always have to request the original filter.

We use the following OrderBy, which I would assume, is not so uncommon:

ORDER BY duedate ASC, priority DESC, type ASC, status DESC, updated DESC

Also v6.1.5 affected

v6.1.7 and v6.2.7 still affected

In that case v6.0.8 is still affected too.

Same behavior for 5.1.7.

Same behaviour in 5.2.11.
Output OK in Filter output but not OK in Filter Result Gadget

Confirm the bug in Jira 5.2.7
instead of using sorting from filter: assignee = currentUser() AND status != Closed ORDER BY status DESC, priority DESC, due ASC, created ASC, issuetype DESC

it uses only first one sort criteria is used it seems (and highlighted despite sortBy=null in request params).

Parameters:
_ 1363720850192
addDefault false
columnNames status
columnNames duedate
columnNames issuetype
columnNames issuekey
columnNames priority
columnNames summary
enableSorting true
filterId filter-10001
num 10
paging true
showActions true
sortBy null
startIndex 0
tableContext jira.table.cols.dashboard

Update:
it didn't worked as expected even for 3 criteria.
Also seems null handling differs in Issue Navigator and Filter Results gadget.
Like "due" is "null last" in Navigator but "null first" in gadget.

PS.
Should we also place a support ticket in addition to https://support.atlassian.com/browse/JSP-152451

Sorry but this can't have something to do with request length.
It's a POST request with for example these query parameters:

filterId	filter-10200
num	20
tableContext	jira.table.cols.dashboard
addDefault	false
columnNames	duedate
columnNames	fixVersions
columnNames	issuetype
columnNames	issuekey
columnNames	priority
columnNames	status
columnNames	summary
columnNames	customfield_10300
columnNames	labels
enableSorting	true
sortBy	null
paging	true
startIndex	0
showActions	true

Content is always requested with "sortBy=null" if the user does not change the sort order in the gadget.
More than 3 ORDER BY are simply ignored on the server side.

Should be really simple to fix this...

P.S.: using JIRA 5.2.1

the problem is not the number of criteria, it's the total length of the request to the server. the more fields you choose and the more sort orders you use, the closer you get to the limit but this depends on the length of the names of the fields too.