Project

General

Profile

Actions

Defect #10048

open

Secondary sorting after sorting by parent task

Added by Jānis Elmeris about 13 years ago. Updated 2 months ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
Issues
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Resolution:
Affected version:

Description

I've created a custom query with two sort orders: 1) Parent task - Ascending (as I want my subtasks be grouped visually together), 2) Updated - Descending (as I want to see the most recently changed tasks at the top).

What I would expect is that
  1. all the tasks without parents would be sorted by their "Updated" value;
  2. all the subtasks within the same parent task would be sorted by their "Updated" value.

As can be seen in the attached screenshot, the actual result in the example of "http://www.redmine.org/projects/redmine/issues" is all the non-parent tasks sorted by their IDs.

All the versions to be submitted along with a bug reports, please take from the current http://www.redmine.org installation, where I'm submitting the defect in. The test screenshot is taken from here.


Files

redmine-sorting.png (78.5 KB) redmine-sorting.png Jānis Elmeris, 2012-01-24 13:06
Screenshot_11.jpg (331 KB) Screenshot_11.jpg Matthew Paul, 2025-02-06 16:41
Screenshot_12.jpg (78.2 KB) Screenshot_12.jpg Matthew Paul, 2025-02-06 16:51

Related issues

Related to Redmine - Feature #7907: Display Issues in a hierarchy (tree)New2011-03-17

Actions
Has duplicate Redmine - Defect #14432: Sorting issues with subtasksClosed

Actions
Has duplicate Redmine - Defect #20123: Can't sort by multiple fields when sorting by parentClosed

Actions
Has duplicate Redmine - Defect #31840: Sort by Parent does not work as expectedClosed

Actions
Has duplicate Redmine - Defect #34818: Do not display in the order set in the custom query!Closed

Actions
Has duplicate Redmine - Defect #38618: it seems to be sorted by issue number instead of parent issue number. After that, setting the sort order has no effect at custom queryClosed

Actions
Actions #1

Updated by Philip Reinders about 13 years ago

I am seeing the same problem. Sort of curious what is going on with this one as it is fairly critical for my implementation.

Actions #2

Updated by Vitaly Klimov about 13 years ago

Please check my plugin - it solves this behavior:

http://www.redmine.org/plugins/redmine_smart_issues_sort

Actions #3

Updated by Asaf H over 12 years ago

+1
We have the same issue. It's problematic as I want to sort issues by priorities, but still have the subtasks grouped under their parent.

Actions #4

Updated by John Pisani about 12 years ago

+1
Parent, Priority just ignores the latter.

Actions #5

Updated by Dipan Mehta about 12 years ago

+1. This is indeed very essential to be in Redmine.

Actions #6

Updated by Anton Potapov about 12 years ago

+1 vote for it

Actions #7

Updated by Toshi MARUYAMA over 11 years ago

  • Has duplicate Defect #14432: Sorting issues with subtasks added
Actions #8

Updated by Sergio Cambra over 11 years ago

+1 I have this problem too

Actions #9

Updated by Zdravko Balorda over 11 years ago

Any news on this?
redmine_smart_issues_sort wouldn't run on 2.3, saying:
undefined method 'issues' for class 'Query'
on line 12 lib/query_patch.rb

Any clues are most appreciated.
Zdravko

Actions #10

Updated by Nicolas Ph about 11 years ago

Well, i have the same issue, a custom query with "Parent task" as first sort field, the second field is ignored, whatever it is. The result look like the second field is set to 'Created'.

The same issue exists when sorting issue by clicking on columns : After adding the 'Parent Task' to the issue view, I click on "Updated" for example, and then on 'Parent Task', the previous 'Updated' order is completely lost.

By the way, the gantt view with the same query seems to work right.

Actions #11

Updated by Toshi MARUYAMA over 9 years ago

  • Has duplicate Defect #20123: Can't sort by multiple fields when sorting by parent added
Actions #12

Updated by Matt Brooke over 9 years ago

+1 causing us a problem and the patch doesn't seem compatible with v 3.1

Actions #13

Updated by Sebastian Paluch over 9 years ago

+100

I'm getting more and more complains about this. We have thousands of issues per project organized in a tree structure and this defect is very, very painful.

Actions #14

Updated by Josh Gitlin about 8 years ago

+1, having the same issue, same use case. I would think this should be a simple fix... but I haven't looked at the code

Actions #15

Updated by Claudio Negri almost 6 years ago

+1

Actions #16

Updated by pizfantast pizfantast about 5 years ago

+1
plugins and patches no longer work

Actions #17

Updated by Go MAEDA over 4 years ago

  • Has duplicate Defect #31840: Sort by Parent does not work as expected added
Actions #18

Updated by Ribald Drobens about 4 years ago

Confirmed here as well; when 1st ordering is for parent issue, ties (i.e. no parent or same parent) are not resolved using any following filter which makes tree-like views practically impossible.

Actions #19

Updated by Go MAEDA about 4 years ago

  • Has duplicate Defect #34818: Do not display in the order set in the custom query! added
Actions #20

Updated by Hirofumi Kadoya about 4 years ago

+1

Actions #21

Updated by txemi M over 3 years ago

+1

Actions #22

Updated by txemi M over 3 years ago

+1

Actions #23

Updated by Sofie vdm over 3 years ago

+1

This is problematic, the secondary sort would be really useful, while still maintaining the parent structure.

Actions #24

Updated by txemi M about 3 years ago

In case it is useful for anyone else.

After waiting for this to be implemented I finally made my own solution.

You can find it here:

https://github.com/txemi/redmine_sorted_tree

It is an small development that creates an extra index that you can use to get hierarchical tree and allows use aditional sorting criterias for deep issues in tree.

It helps me to get human reports sorting issue tree as I want.

Actions #25

Updated by Go MAEDA about 1 year ago

  • Has duplicate Defect #38618: it seems to be sorted by issue number instead of parent issue number. After that, setting the sort order has no effect at custom query added
Actions #26

Updated by Matthew Paul 2 months ago

I have a codefix for this problem but I'm using an old version (3.4) and I'm not real great with plugins etc, so I thought I could post this here since a) it seems a lot of people have bee looking for a fix, and b) if it hasn't already been fixed in the pater versions (I'm assuming it has!) then this could be a useful way to do this. It's kind of a hack but here we go -

  • PROBLEM - On a project with a lot of parent/child tasks, you often want to sort 1) by the parent, then 2) by whatever field you want afterwards, like status, or subject, or whatever. But a multi field sort doesn't work like that - the secondary sort is just ignored.
  • CAUSE - if you look at the code under app/models/issue_query.rb, you can see under the class IssueQuery that it uses this code for a parent sort -

QueryColumn.new(:parent, :sortable => ["#{Issue.table_name}.root_id", "#{Issue.table_name}.lft ASC"], :default_order => 'desc', :caption => :field_parent_issue),

which means that it will sort by the root_id first (the top level task) and then by the internal lft field which is maintained internally. Some plugins are available to move that lft/rgt ordering around but I couldn't get those to work in my (old) version. So I wanted to change that sort.

  • SOLUTION - what I want is for the upper level sort to occur with the parent level task at the top, and then all of the subtasks below, UNORDERED. This is important, because what I want to do is sort those subtasks however I want - by subject, by ID, by status, by priority etc. SO anyways, this is the code that does that (yeah, it's a hack, I'm sure it could be done better by pretty much anyone, but I'm desperate here!! :-) )

Replace the code above with this -

QueryColumn.new(:parent, :sortable => ["#{Issue.table_name}.root_id", "if (#{Issue.table_name}.rgt - #{Issue.table_name}.lft > 1, #{Issue.table_name}.id+0, #{Issue.table_name}.parent_id+0.1) ASC"], :default_order => 'desc', :caption => :field_parent_issue),

So what that does is to say first of all use the root_id as normal, but then if the rgt/lft values indicate that it's got subtasks (i.e. an rgt-lft value over 1 indicates this) then use the id itself, but if it hasn't, then use the parent_id (i.e. the upper level) plus some additional number (I've used 0.1 here). So the upper task will appear at the top, and subtasks below UNORDERED as you want.

EXAMPLE - this is the query I used to test it out.


Anyways, like I say this is a hack because I just use this code internally, but if anyone could build it into a simple patch or plugin or (if it hasn't already been solved in later versions) the base code could be updated, I think this seems to work. My apologies to everyone that I'm not good enough to do all of this properly but I thought the fix might be useful and wanted to contribute back to what I always think is the BEST all-in-one tracker/PM tool at any price. Redmine ROCKS!

Actions #27

Updated by Matthew Paul 2 months ago

....actually now I think of it, if this were a plugin, it would be better if you retained the same behavior for Parent Task sort, but added an option for something like Parent Plus or similar so people could either select the regular Parent+Lft sort, or do a Parent+whatever sort.

Actions #28

Updated by Matthew Paul 2 months ago

PPS - only works for single level trees which is ok for me, but again if someone were better than me (ie. everyone) and could construct a sort string all the way down that would be better. Or, as I said just include as a sort option.

Actions

Also available in: Atom PDF