Defect #34398
closed
Tracker filter shows subprojects trackers even when "Display subprojects issues on main projects by default" is disabled
0%
Description
Currently, the tracker filter shows all trackers enabled in the current projects and subprojects. However, it makes no sense to show subprojects trackers when "Display subprojects issues on main projects by default" (Setting.display_subprojects_issues) is disabled because filtering by those trackers always shows no issue.
Assume that there are two projects, p_main and its subproject p_sub. foo and bar trackers are enabled for p_main, and bar and baz trackers are enabled for p_sub.
| Project | Enabled trackers |
|---|---|
| p_main | foo, bar |
| p_sub | bar, baz |
Tracker filter in p_main has 3 options, foo, bar, and baz. It is OK because issues in p_sub is displayed in p_main as well by default.
When you turn off "Display subprojects issues on main projects by default" setting, issues in p_sub are no longer displayed in the issues list of p_main. This means that all issues displayed in p_main should belong to one of the two trackers, foo or bar. However, the tracker filter still shows a tracker baz which is only enabled in the subproject baz. The option baz in the tracker filter is useless because issues with baz tracker are never displayed in p_main's issues list.
Setting.display_subprojects_issues |
Possible trackers in p_main's issues list | Available options for trackers filter |
|---|---|---|
| '0' | foo, bar | foo, bar, baz |
| '1' | foo, bar, baz | foo, bar, baz |
Files
Updated by Yuichi HARADA over 3 years ago
- File 34398.patch 34398.patch added
I fixed it like that it does not show subprojects trackers when "Display subprojects issues on main projects by default" (Setting.display_subprojects_issues) is disabled.
diff --git a/app/models/query.rb b/app/models/query.rb
index 18f1b135bf..74bb5e50a2 100644
--- a/app/models/query.rb
+++ b/app/models/query.rb
@@ -493,7 +493,7 @@ class Query < ActiveRecord::Base
end
def trackers
- @trackers ||= (project.nil? ? Tracker.all : project.rolled_up_trackers).visible.sorted
+ @trackers ||= (project.nil? ? Tracker.all : project.rolled_up_trackers(Setting.display_subprojects_issues?)).visible.sorted
end
# Returns a hash of localized labels for all filter operators
Updated by Mischa The Evil over 3 years ago
- Status changed from New to Needs feedback
- Assignee set to Go MAEDA
@Go MAEDA:
I do not think this is a good idea. I'll use a quote from you which will clearly explain, without going into all the technical details, why.
When you turn off "Display subprojects issues on main projects by default" setting, issues in p_sub are no longer displayed in the issues list of p_main.
That quote is true but incomplete. That setting is, as the name implies, just setting a default for every issue query. That default value can be normally modified by each user for every query using the 'Subproject' issue filter, as it should be IMHO.
So to come back to your quote, it is true but conditional. In your example the condition being: ... unless the filter 'Subproject' is set to 'any' or 'is' with a particular value.
This is and has traditionally been something that is quickly overlooked1. Maybe it would help if the setting is moved to the 'Isuses list defaults' group on the 'Issue tracking' tab of the settings page? Wait what?
But, if this is the case for this setting, then what about the same behaving 'Use current date as start date for new issues' setting? Maybe (better) documentation would/could help too.
However, given my current perspective of the current situation of the Redmine project, I think this is a futile matter as there are much more and, more importantly, more important things that IMO need handling first.
Coming back to this issue, I'd say we can close it as either invalid or wont fix. What do you think?
1 to the point that the ChiliProject team even implemented a duplicated subset of the filter feature as a separate issue query option (https://www.chiliproject.org/issues/672.html [commit: 2b7a221 on GitHub]), which provided fun results when used together with the then already present 'Subproject' filter ;) Those were the days...
Updated by Go MAEDA over 3 years ago
- Status changed from Needs feedback to Closed
- Resolution set to Invalid
Mischa The Evil wrote:
That quote is true but incomplete. That setting is, as the name implies, just setting a default for every issue query. That default value can be normally modified by each user for every query using the 'Subproject' issue filter, as it should be IMHO.
So to come back to your quote, it is true but conditional. In your example the condition being: ... unless the filter 'Subproject' is set to 'any' or 'is' with a particular value.
I did not know about this behavior until just now. Thank you for pointing this out. Now I understand that what I wrote in this issue's description makes such queries impossible.
Coming back to this issue, I'd say we can close it as either invalid or wont fix. What do you think?
I agree completely.