Redmine

Suppose you have a project P which has subprojects P1. Further you have a global, saved issue query with a project_id filter for just the subproject P1.

When calling that query in the context of P (by going to /projects/p/issues?query_id=123), only issues of P1 are shown. The same is true for the PDF export when accessed from this page. However, the CSV export when accessed from the same page, will contain issues from P as well.

The cause of that discrepancy is, that the modal CSV export options window serializes the query into a bunch of hidden fields, while the PDF export just uses the query_id URL parameter, like the web UI view does.

Deeper down, the problem is the timing of when @query.project is set in QueriesHelper#retrieve_query: With query_id present, the query is loaded and then the project is set. Without query_id (in the CSV export case), the project is set first, before the params are applied. This results in a different available_filters configuration, because only in absence of the project, the project_id filter will be added. So with the project being set early, the project_id filter isn't initialized in the query object and thus all issues of P are rendered in the CSV. I'm attaching a failing test case illustrating the problem.

I tried two approaches to solve the problem but both weren't really straightforward and I'm not sure which one to pursue further.

1. Use query_id in the hidden fields of the modal instead of serializing all the filters. I changed the query_as_hidden_field_tags helper for this, basing it's output on Query#as_params. That worked somewhat but at least the 'all columns' option would need special treatment in this case because it was ignored.
2. Change QueriesHelper#retrieve_query to not initialize the new query with the project when creating it, but apply the params first and set the project later. While this solved my case, it broke a lot of other test cases in both issues and timelog_reports controller tests.
3. There might be a better way to fix this in IssueQuery itself, by differentiating the cases of 'should I show the project filter in the UI' (only if called outside project context) from 'should I apply an already set project filter' (yes, if the projects filtered for are sub-projects of the present project).

Opinions, anybody?

The problem is present at least since 3.3, I worked on current trunk (r17320).