Project

General

Profile

Actions

Patch #6431

closed

Allow parent task field to be used in filters

Added by Stuart Cianos over 13 years ago. Updated about 6 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
Issues
Target version:
-
Start date:
2010-09-18
Due date:
% Done:

0%

Estimated time:

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.


Files

scvmc_redmine_6397_parent_task.diff (3.6 KB) scvmc_redmine_6397_parent_task.diff Patch which implements feature 6397 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 queryClosed2010-09-15

Actions
Related to Redmine - Feature #6118: Filter by parent task or subtasksClosedJean-Philippe Lang2010-08-12

Actions
Actions #1

Updated by Stuart Cianos over 13 years ago

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

Actions #2

Updated by Gray Wizard over 13 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" },

Actions #3

Updated by Stuart Cianos over 13 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" },

Actions #4

Updated by Gray Wizard over 13 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"

Actions #5

Updated by Stuart Cianos over 13 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).

Actions #6

Updated by Gray Wizard over 13 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"?

Actions #7

Updated by Gray Wizard over 13 years ago

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

Actions #8

Updated by Stuart Cianos over 13 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

Actions #9

Updated by Daniel Thornton almost 13 years ago

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

Actions #10

Updated by Stuart Cianos almost 13 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?

Actions #11

Updated by William Lafleur about 12 years ago

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

Actions #12

Updated by shravan kumar about 11 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

Actions #13

Updated by Luis Serrano Aranda about 10 years ago

+1

Actions #14

Updated by @ go2null about 6 years ago

As #6118 is implemented, shouldn't this be closed?

Actions #15

Updated by Mischa The Evil about 6 years ago

  • Status changed from New to Closed

@ go2null wrote:

As #6118 is implemented, shouldn't this be closed?

You are right. Thanks for your comment. I'll close this issue.

Actions

Also available in: Atom PDF