Patch #6431

Allow parent task field to be used in filters

Added by Stuart Cianos over 7 years ago. Updated almost 4 years ago.

Status:NewStart date:2010-09-18
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:Issues
Target version:-

Description

This patch allows the parent task field to be used in filters.

The patch also corrects a potential bug in the SQL code generation for grouping of columns with both a specified sort order and a default sort order, based on Redmine's current implementation of subtasking as a sort order.

This patch resolves #6397.

scvmc_redmine_6397_parent_task.diff Magnifier - Patch which implements feature 6397 (3.6 KB) Stuart Cianos, 2010-09-18 03:20


Related issues

Related to Redmine - Feature #6397: Add Parent Task field as a sort criterium when defining a... New 2010-09-15
Related to Redmine - Feature #6118: Filter by parent task or subtasks Closed 2010-08-12

History

#1 Updated by Stuart Cianos over 7 years ago

One additional note: This also implements the ability to specify a custom caption when defining filter fields.

#2 Updated by Gray Wizard about 7 years ago

I found a small "feature" in the submitted patch.

"root_id" => { :type => :integer, :order => 16, :caption => "field_parent_issue" },

should be:

"parent_id" => { :type => :integer, :order => 16, :caption => "field_parent_issue" },

#3 Updated by Stuart Cianos about 7 years ago

Reason for the use of root_id was based on the previous specification in current production source. Reference is:

Line 124 (app/models/query.rb): QueryColumn.new(:parent, :sortable => ["#{Issue.table_name}.root_id", "#{Issue.table_name}.lft ASC"], :default_order => 'desc', :caption => :field_parent_issue)

Is there a reason parent_id is reccomended as apposed to the above spec from the original querycolumn definition?

Gray Wizard wrote:

I found a small "feature" in the submitted patch.

"root_id" => { :type => :integer, :order => 16, :caption => "field_parent_issue" },

should be:

"parent_id" => { :type => :integer, :order => 16, :caption => "field_parent_issue" },

#4 Updated by Gray Wizard about 7 years ago

Stuart Cianos wrote:

Reason for the use of root_id was based on the previous specification in current production source. Reference is:

Line 124 (app/models/query.rb): QueryColumn.new(:parent, :sortable => ["#{Issue.table_name}.root_id", "#{Issue.table_name}.lft ASC"], :default_order => 'desc', :caption => :field_parent_issue)

Is there a reason parent_id is reccomended as apposed to the above spec from the original querycolumn definition?

Gray Wizard wrote:

I found a small "feature" in the submitted patch.

"root_id" => { :type => :integer, :order => 16, :caption => "field_parent_issue" },

should be:

"parent_id" => { :type => :integer, :order => 16, :caption => "field_parent_issue" },

I must confess I don't know the DB structure of Redmine very much at all but the "root_id" is not linked (in our instance) to the parent issue at all. As a matter of fact I am not sure what the root_id refers to as the values in that column exceed the id values I have in my projects, versions, and ticket tables. I assume that they must relate somehow to the parent issue but it is not a direct link, at least not in the latest "Bitnami Redmine Stack for Windows"

#5 Updated by Stuart Cianos about 7 years ago

Gray Wizard wrote:

I must confess I don't know the DB structure of Redmine very much at all but the "root_id" is not linked (in our instance) to the parent issue at all. As a matter of fact I am not sure what the root_id refers to as the values in that column exceed the id values I have in my projects, versions, and ticket tables. I assume that they must relate somehow to the parent issue but it is not a direct link, at least not in the latest "Bitnami Redmine Stack for Windows"

On further review, I think we're both wrong... The root_id points to the issue id of the top branch within the "tree of subtasks". They are storing the tree in the database (i.e. the lft, rgt columns and henceforth their use of those columns with the root_id for ordering, as described above). This makes for an interesting dilemna in some respects, since this means that using the parent_id would require a user to have an "or" condition to include children more than one branch away... I'll have to play around with the code to see if there is a better way (anyone else with ideas, please chime in!)

Regarding your strange ID#'s:

You noted the root_id is pointing to nonexistent id's in your db. What version of Redmine is included in the Bitnami stack (from Administration->Information)? In 1.0.1 (current production in my organization) and SVN trunk I show the root_id linked to either the root parent or, if parent_id is null, itself. Example:

'id', 'parent_id', 'root_id'
'414', '478', '478'
'415', NULL, '415'
'416', '478', '478'
'417', '437', '437'
'418', '437', '437'
'419', '437', '437'
'420', '437', '437'
'421', '437', '437'
'422', '436', '436'

In this case, row 415 has no parent_id, so root_id links to itself. For 416-421, 437 the parent_id and root_id is set accordingly (which is correct).

#6 Updated by Gray Wizard about 7 years ago

Stuart Cianos wrote:

Gray Wizard wrote:

I must confess I don't know the DB structure of Redmine very much at all but the "root_id" is not linked (in our instance) to the parent issue at all. As a matter of fact I am not sure what the root_id refers to as the values in that column exceed the id values I have in my projects, versions, and ticket tables. I assume that they must relate somehow to the parent issue but it is not a direct link, at least not in the latest "Bitnami Redmine Stack for Windows"

On further review, I think we're both wrong... The root_id points to the issue id of the top branch within the "tree of subtasks". They are storing the tree in the database (i.e. the lft, rgt columns and henceforth their use of those columns with the root_id for ordering, as described above). This makes for an interesting dilemna in some respects, since this means that using the parent_id would require a user to have an "or" condition to include children more than one branch away... I'll have to play around with the code to see if there is a better way (anyone else with ideas, please chime in!)

Regarding your strange ID#'s:

You noted the root_id is pointing to nonexistent id's in your db. What version of Redmine is included in the Bitnami stack (from Administration->Information)? In 1.0.1 (current production in my organization) and SVN trunk I show the root_id linked to either the root parent or, if parent_id is null, itself. Example:

'id', 'parent_id', 'root_id'
'414', '478', '478'
'415', NULL, '415'
'416', '478', '478'
'417', '437', '437'
'418', '437', '437'
'419', '437', '437'
'420', '437', '437'
'421', '437', '437'
'422', '436', '436'

In this case, row 415 has no parent_id, so root_id links to itself. For 416-421, 437 the parent_id and root_id is set accordingly (which is correct).

Upon further review you nailed it on the head, the root_id was the id if there was no parent_id, I had not double checked my numbers well enough (just re-ran the query). In our case we only have one level of sub-task by policy so it is not a huge problem for our implementation, but it would indeed break for anything deeply nested. Is there a problem with with changing the query to be "parent_id=X OR root_id=X and ID != X" for "child tasks"?

#7 Updated by Gray Wizard about 7 years ago

Forgot to mention we are running 1.0.1 (stable) on mySQL

#8 Updated by Stuart Cianos about 7 years ago

Gray Wizard wrote:

Upon further review you nailed it on the head, the root_id was the id if there was no parent_id, I had not double checked my numbers well enough (just re-ran the query). In our case we only have one level of sub-task by policy so it is not a huge problem for our implementation, but it would indeed break for anything deeply nested. Is there a problem with with changing the query to be "parent_id=X OR root_id=X and ID != X" for "child tasks"?

I'll have to check it out to see if the current implementation can handle multiple field references... if not, will be a weekend project since the organization I work for needs this feature :)

- Stu

#9 Updated by Daniel Thornton over 6 years ago

I am unable to get this patch working in version 1.1.1.stable or in svn trunk.

#10 Updated by Stuart Cianos over 6 years ago

Thanks for the heads up... We're running 1.1.2 right now without issue.

What errors are you getting/did the patch not apply cleanly?

#11 Updated by William Lafleur almost 6 years ago

Would it be a good idea to apply this patch to version 1.3.0?

#12 Updated by shravan kumar almost 5 years ago

Getting internal with this patch.

I have redmine 1.4.4

When i make change in /app/views/quires/_filters.html.erb

<%= select_tag 'add_filter_select', options_for_select("","" + query.available_filters.sort{|a,b| a1[:order]<=>b1[:order]}.collect{|field| [ field1[:name] || (field1[:caption] == nil ? l(("field_"+field0.to_s.gsub(/_id$/, "")).to_sym) : l(field1[:caption].to_sym)), field0] unless query.has_filter?(field0)}.compact),

I get Internal error.

Can please hepl to resolve this issue

Also available in: Atom PDF