Order by the same ticket order as shown in the "IN" clause

[mohamad]

Hello,

I have a JQL that has an "IN" clause which contains a list of jira tickets IDs. I want to show this list of returned jira tickets in the same order as listed in the "IN" clause. Here's the JQL script:

id in (PENNY-2852, PENNY-2853, PENNY-2854, PENNY-2855, PENNY-2856, PENNY-2857, PENNY-2858, PENNY-2860, PENNY-2861, PENNY-2862, PENNY-2863, PENNY-2864, PENNY-2865, PENNY-2866, PENNY-2867, PENNY-2868, PENNY-2872, PENNY-2873,PENNY-2898,PENNY-2896,PENNY-2897,PENNY-2913,PENNY-2912,PENNY-2935,PENNY-2911,PENNY-2934,PENNY-2915,PENNY-2933,PENNY-2914) "

ORDER by key does not help much as the tickets could be created in any random order but the order mentioned in the "IN" clause should be maintained. How can I achieve that?

[dkamath]

id in (PENNY-2852, PENNY-2853, PENNY-2854, PENNY-2855, PENNY-2856, PENNY-2857, PENNY-2858, PENNY-2860, PENNY-2861, PENNY-2862, PENNY-2863, PENNY-2864, PENNY-2865, PENNY-2866, PENNY-2867, PENNY-2868, PENNY-2872, PENNY-2873,PENNY-2898,PENNY-2896,PENNY-2897,PENNY-2913,PENNY-2912,PENNY-2935,PENNY-2911,PENNY-2934,PENNY-2915,PENNY-2933,PENNY-2914) ORDER BY id

[Nic Brough -Adaptavist-]

There's no way to do that.  Your "in" clause has nothing to do with ordering.

You'll need to look at other data on the issues for your sort.

[mohamad]

Why tickets are not ordered by the same order sent in the "in" clause should not be the case? Any suggested workarounds?

[Nic Brough -Adaptavist-]

Why would they be? 

A question asking for a list of issues is one thing.  How you display it (including the sort order if one even applies in your result report) is another thing.

You'll need to look at something else to do the ordering.

[Sambit Mishra]

I see this as a very valid and common sense requirement. I expect the query to return me back a report exactly in the same order as my input queue is. I didnt expect jira to apply a default ordering I never asked. 

The use cases are far reaching and very relevant for collabs - I may get a input stream of data from any source and post my specific query processing - the order if maintained is a simple match key option / or match sequence - than an elaborate post or pre-processing i need to do now - just because JIRA defaulted to some ordering which was never asked.

[Nic Brough -Adaptavist-]

Welcome to the Atlassian Community!

I'm sorry, but that makes no sense.  Of what use is a search ordered by an arbitrary list of issue keys?  What problem would that solve?  Or more importantly, what question would it answer?  How would it help someone reading the results?

[Sambit Mishra]

Thank you :)

Well, before I go on about use cases, in standard software engineering practice isn't auto ordering when not asked to do so is a violation of an implicit requirement to maintain input order?

Again the use cases can be varied and can certainly be solved to work around this assumed auto ordering by JIRA - but needs additional intervention in some cases.

One example is crossing inputs from JIRA to another database or list - where the key might be something else for ordering, so the JIRA id list should just return back in the same order that it was entered.

[Nic Brough -Adaptavist-]

No, ordering by a picked list personal to the human is not a standard engineering practice anywhere.

I can not think of any use for ordering by a human's decision list outside what that human is opining (and when a human opines, we are frequently wrong)

Again, could you tell us what use an ordering by a fixed list is for a group of people who have different opinions and a wider understanding of the area?

What problem would that solve?  Or more importantly, what question would it answer?  How would it help someone reading the results?

[Kyle Schutter]

Chiming in that my use case would appreciate this feature - I am sending a list of issue keys that might be different from their current keys - the search returns the current keys but I need to match the current keys with the row that contains the old key.

[Nic Brough -Adaptavist-]

@Kyle Schutter   Welcome to the Atlassian Community!

I think you may be missing the point here, why do you think you need to "send a list of arbitrary issue keys" for something?

[Kyle Schutter]

When creating certain tickets, my team keeps track of them on a google sheets, and we've been using the JIRA() function to keep track of their statuses. Now that the number of tickets is approaching 50, individual calls for each ticket has started rate limiting the sheet. My solution was to create another sheet that simply made one call for all the tickets being tracked, which uses their original keys to make the request, then use VLOOKUP on the other sheets to request relevant details. The response, however, only returns the current key, making it impossible to match the old keys with the new if they've been moved between projects. 

Since there's no current way to request a table of all keys that have been moved, the easiest solution would be to request a custom sort order so that the index of the requested key is identical to the return.

[Peter Brown]

this i think is a very valid request. Here's our usecase...

we have some dashboards that pulls data from multiple sources (primarily our support ticketing system and salesforce account information) and provides an ordering based on data that is not present in the jira system. This dashboard then presents an ordered view of the jira tickets that are involved (in descending order) of the most number of support cases. As mentioned, that information is not available in the jira system.

From the dashboard, there is a link that opens the issues in Jira, and the intention/requirement is that the list of issues remains sorted in that same order; such that the support team can talk about Issue #1, and the engineering team can dig into the jira query and look at the same issue #1.

WIth this weird ordering thing here, since ordering is not maintained, therei s no way to correlate #1, #2, #3 on the support dashboard with the resulting query in jira.

As mentioned above by several other folks; this is a valid usecase, and I would not expect Jira to apply any sort of 'invisible' sorting. i asked in the query for the issues in a specific order, and so I would expect them to be presented in that order.

please advise