Feature #6116
openGroup sub-tasks with parent on issue list
0%
Description
My colleagues have starting re-arranging their issue lists now that we have subtasks and every single one of them has asked how they can change the issue listing to make it obvious at a glance which subtasks belong to which issue.
Having this ability is a critical feature I think to make subtasks manageable.
Something like:
Put all subtasks under their parent tasks in the issue listing.
add a - or > in the issue title as basic indentation.
I imagine this won't be a simple change because it will affect how the table ordering code should work.
Files
Related issues
Updated by Jeffrey Jones about 14 years ago
Actually looking at it, probably the easiest thing to do would be to use the group by functionality already in the system to group the subtasks
Updated by Xagyg Wulf about 14 years ago
Add "Parent Task" column to the issues list. Sort on parent task column. An arrow is placed for subtasks of a parent and grouped under it.
Updated by Jeffrey Jones about 14 years ago
Aha, that is perfect, just what I want. Apart from the fact that we have to have the parent task column visible which takes up a lot of space we would rather use for other stuff.
A way to get this exact layout without having to have the parent task column visible would be perfect.
Updated by Mischa The Evil about 14 years ago
- Category changed from Issues to UI
Updated by Nicolas Connault almost 14 years ago
What you are trying to do is possible in Redmine 1.0.3. You need to create a custom query that sorts by parent task without adding the parent task column to the list. Here's how to do it:
Above the issues list, there should be 3 buttons: Apply, Clear and Save. These buttons refer to the filters and other options above them. When you click on save, it takes you to the New Query page.
*Name your query (e.g. Sort by Parent Task)
*Tick Public, All projects and Default columns
*Select "Parent Task" in the first drop-down under the "Sort" section, then "Ascending" in the next drop-down to the right
*Add any other sorts or filters (sorting by Priority and/or date submitted is probably useful)
*Click Save
Now this query will be the default view for all issue lists, and hopefully for all users (I haven't tried logging as a different user).
Updated by Nicolas Connault almost 14 years ago
Update: the custom query is available to all users, but is not selected by default. Also, I don't know how to edit or delete a custom query once it has been created. I'm sure it's possible.
Updated by Tomasz Sawicki over 13 years ago
In order to sort by parent task and task id by default (which makes the subtask tree appear) in app/controllers/issues_controller.rb find index method and change
sort_init(@query.sort_criteria.empty? ? [['id', 'desc']] : @query.sort_criteria)
to
sort_init(@query.sort_criteria.empty? ? [['root_id', 'desc'], ['id', 'desc']] : @query.sort_criteria)
Updated by Tomasz Sawicki over 13 years ago
- File issues_default_sort_by_root_id_and_id-1.3.1.patch issues_default_sort_by_root_id_and_id-1.3.1.patch added
Attached patch for 1.3.1 adding root_id desc to default sort order.
Updated by arthur me over 13 years ago
Patch applies correctly for me. This is an extremely handy feature.
Updated by Lukas Elmer over 13 years ago
+1
arthur me wrote:
Patch applies correctly for me. This is an extremely handy feature.
Updated by Steffen Tischer about 13 years ago
Thanks for that path. It is very useful.
But i have one question: If i set another sort column i can not reset this settings to default sort order.
In my opinion it is useful to reset also the sort setting if i click on "Reset" on top of the list. This button clears all setting except the sort settings.
Is this possible?
Updated by Mischa The Evil almost 13 years ago
Isn't this issue a duplicate of #5325?
Updated by Marco Shima over 3 years ago
Updated by Jim Jiminson almost 3 years ago
Tomasz Sawicki wrote:
Attached patch for 1.3.1 adding root_id desc to default sort order.
Is there an easy way to do this for other sorting? Sorting by root_id first seems to invalidate/break secondary sorts.