Redmine

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

@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 overlooked¹. 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?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?

¹ 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...

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.