I use filter X and get 29 results. I add an ORDER BY clause, say "ORDER BY assignee" and see only 3 results. Clearly, ordering should not affect the cardinality of the result set. This happens when I order by inbuilt fields like assignee and also when I order by custom fields. Whatever field I'm ordering by, I see the same 3 issues.
I recall another community question with this same symptom last week: adding an ORDER BY clause to a JQL search reduced the list of returned work items (formerly called "issues").
As there was no resolution to that one I recommend working with your Site Admin to submit a defect to Atlassian Support for this: https://support.atlassian.com/contact/#/
When you hear back from them, please post what you learn to benefit the community. Thanks!
Kind regards,
Bill
Thanks, Bill. I have submitted a case to Atlassian. When I hear back from them I'll post here for the community. Since they have access to my instance they'll be better able to diagnose than we can in the community. I've heard suggestions that a reindex might solve the problem, but that's not available to me as just a site admin since we're on a Cloud account.
BTW, my "answer" with relocating the NOT in my query worked for my minimal test case.... but not for the case where it actually matters to me, the one affecting the dashboard queries our managers rely upon. However, the "answer" is worth keeping here since it might help someone else.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I think I've got it. In the saved filter I had this clause:
AND NOT (
("Releasable Build[Dropdown]" IN (
6.01, 6.02, 6.03, 6.04, 6.05, 6.06, 6.07, 6.08, 6.09, 6.10, 6.11, 6.12, 6.13, 6.14, 6.15, 6.16, 6.17, 6.18
))
But MOVING THE NOT fixes things so the filter AND the reference call to the filter behave the same way
AND (
("Releasable Build[Dropdown]" NOT IN (
6.01, 6.02, 6.03, 6.04, 6.05, 6.06, 6.07, 6.08, 6.09, 6.10, 6.11, 6.12, 6.13, 6.14, 6.15, 6.16, 6.17, 6.18
))
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Yes, that fixes my test case. But it doesn't fix my general case. Still working on this.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
More experiments suggest a problem with referencing filters in queries. Sadly, I've done that a lot since it makes maintenance of dashboards and other filters much easier.
To illustrate, I create a filter that returns 30 items. Ordering by all the fields I tested (some custom, some inbuilt) always returns 30 items. Note that when I save this filter I do not apply any ordering.
Call the saved filter "foo" and call its filter ID 12345 for the subsequent description.
Now, I use the saved filter by REFERENCING it, e.g. ("filter = foo" or "filter in (foo)" (in both instances allowing Jira to auto-complete) or "filter in (12345)" or "filter = 12345") I suddenly get 812 rows back. If I apply an ORDER BY clause on SOME fields (e.g. "assignee" or one of my custom fields "resolved by" which is "cf[10033]) I get 30 rows. On OTHER fields (e.g. "key", "resolution" inbuilt fields or a sampling of my custom fields) I get 812 again.
I'm considering the painful workaround of hunting down all the places where I reference saved filters and expand those filters inline. But I'd much rather find an actual solution that allows me to keep my makeshift modularization.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @datacore-bwelsh ,
Can you check if this is happening only to you or to other users? Also, have you tried using different browsers to check if the issue persists?
Also, is this happening only when you add ORDER BY to a specific filter or in any advanced item search?
I've tried recreating this in all scenarios all items are displayed as they should.
Potentially, you could try reaching out to Atlassian Support to let them have a look at this within your instance.
Cheers,
Tobi
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Tobi. Thank you so much for your reply. Yes, it's happening to other users. The problem was discovered when someone using a dashboard tried to get an ordering in the table and lost most of his results.
Let me see if I can come up with a small test case to reproduce. So far, it seems to have to do with referencing saved filters and trying to apply an ordering.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
The odd results (my "30 versus 812 items depending on the ordered-by field") shows up in Firefox as well.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.