nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

ORDER BY key vs. BY issuekey vs. BY rank

Gero_C__Sifferath

Are "key", "issuekey" and "rank" synonyms? If not, what is the difference?

And - in case it isn't one of the above - ist there a chance to order the result of an query of Subtasks the same way the subtasks are ordered in the "Tab" "Unteraufgaben" ("Subtasks" I guess) in the parent ticket, given the order was manually changed in this "Tab".

Accepted answers

Nic Brough -Adaptavist-

Yes and no. "Issue key" is usually just called "key" by most of us.

Rank is the order in which you have placed a set of issues, it has nothing to do with the key.

All comments

Nic Brough -Adaptavist-

Yes and no. "Issue key" is usually just called "key" by most of us.

Rank is the order in which you have placed a set of issues, it has nothing to do with the key.

Gero_C__Sifferath

Thank you Nic!

I understand that "issuekey" and "key" are synonyms.

If "Rank" is the order in which issues are placed (physical order - correct?), it is technically something else, but practically it leaves the same difference - doesn't it?

But what ist the name of the "key" that controls the order of subtasks within the table of the parent issue? "Order by rank" isn't changed if you change the "rank" of a subtask later on. So there must be at least one more "key", that controls this order.

Gero_C__Sifferath

Sorry 1: I've used the wrong windows - what is shown as a 2nd answer was supposed to be a reply to Nic!

Sorry 2: Of course "order by rank" or "order by key" does make a difference if you select issues from more then one projekt ...

Nic Brough -Adaptavist-

Rank is a semi-hidden field (the contents are not human friendly) which you can use for ordering in filters. It's not really an absolute value, it's a relational pointer. You "edit" it by moving issues relative to each other.

The order you see sub-tasks in on a parent is still ranked, but it's local to the parent issue, it has no relevance when you're ranking a list of issues because it is irrelevant and useless outside the parent - the parent already has a rank.

Gero_C__Sifferath

Thanks again Nic!

"it is irrelevant and useless outside the parent" - sorry, can't agree. Actually the trigger for this post was to find a way to use it outside the parent. The simple reason is, that working on an issue with e.g. 20 subtasks is quite annoying. Each time you jump back from a subtask you have to scroll for the list. When you open another subtask you loose overwiev of the list. So I use a query like "parent = XYZ-165 OR issuekey = XYZ-165 ORDER BY summary".

But the only way I have found so far to retain the correct order in the list is by numbering the summaries manually - not really sophisticated.

Well, I have to admit, that I'm kind of abusing Jira for project management - since we don't have no PM-Programm in my company. And that I have a feeling there are better ways to work with Jira - but no one in my company really knows ... thus I've ended up with a requirement you judge irrelevant and useless ;-)

Nic Brough -Adaptavist-

Mmm, the reason I say it's useless is that ranking a subtask outside the parent is wrong.

If you have a sub-task that should be ranked over another story then there's something wrong with your ranking.

Either the sub-task is on a story that is ranked too low and needs bumping up, or the sub-task is something that should be its own story. Either way, ranking sub-tasks outside their parent is nonsense - you can't logically say "this part of Y that has a lower priority than X is more important than X".

But this is not uncommon - it happens when people get lost in a morass of dependencies and are too afraid to split work up better or criticise someone else who had not seen that the stories are the wrong shape. A desire to rank sub-tasks incorrectly should not be seen as a problem that needs working around, it is just indicative that planning has uncovered an unforeseen dependency or chain of work that needs re-planning.