Defect #25828


Issue visibility problems on 3.3.1

Added by Leo Antunes about 7 years ago. Updated about 7 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
Affected version:



We've recently migrated from 2.5.1 to 3.3.1 without any noteworthy problems. However, after migration we started noticing a few strange problems affecting non-admin users:
  • Some trackers are missing from project's overview pages and the existing ones have massively reduced issue counts.
  • Clicking on "View all issues" on the overview page leads to an empty issues list.
  • However: clicking on "Issues" on the project's navbar leads to correct listings (the only difference seems to be the "?set_filter=1" querystring).
  • Following the same pattern: changing the filter leads to empty lists, which then work after clicking on "Issues" on the navbar again (so, again, "?set_filter=1" seems to be the only difference)
  • The issues API also delivers empty results as soon as a filter is provided (simply accessing issues.json without a filter shows the appropriate issues)

The admin users see everything as it should be, leading me to believe this might be a permission issue, but we double and triple-checked all settings.
We also cloned the whole redmine instance and removed all plugins to make sure this wasn't caused by some monkey-patching of models.

I couldn't find any existing issue mentioning any similar behavior.


redmine_project_overview_workaround.patch (1.05 KB) redmine_project_overview_workaround.patch workaround for project overview and tracker totals Leo Antunes, 2017-05-16 17:30
redmine_issues_api_workaround.patch (516 Bytes) redmine_issues_api_workaround.patch workaround for issues API and issues filter changing Leo Antunes, 2017-05-16 17:30

Related issues

Related to Redmine - Defect #26376: Wrong issue counts and spent time on project overviewClosedJean-Philippe Lang

Actions #1

Updated by Leo Antunes about 7 years ago

Seems to be something going on here.

Actions #2

Updated by Leo Antunes about 7 years ago

It seems the query to load project membership data is using Traversing.descendants instead of Traversing.self_and_descendants while joining on project, so the subsequent query for issues gets only the list of subproject-ids as filter and therefore delivers an empty result-set (because in our case the issues are associated to the parent project, not the subprojects).

The following change to initialize_available_filters in app/models/issue_query.rb "fixes" part of the issue, but it's obviously not the right solution:

- subprojects = project.descendants.visible.to_a
+ subprojects = project.self_and_descendants.visible.to_a

With this change the trackers still don't work, but the API and the "Issues" page for the parent-project work again. But it still doesn't make much sense to me, how this "leaks" to the actual membership query, which is performed in User.projects_by_role, which in turn is used in Project.allowed_to_condition.

PS.: we also tested updating to 3.3.3 without any change. The problem persists.

PPS.: sorry if my notation is unclear. I'm not a ruby dev, so I'm kinda learning the ropes as I go ;)

Actions #3

Updated by Leo Antunes about 7 years ago

Calling User.projects_by_role in the rails console returns the right result, but the same method is returning the wrong projects on runtime. My layman impression is that something is monkey-patching the Member.joins(:project) call inside User.projects_by_role to include a call to Traversing.descendants. Some information from IssueQuery.initialize_available_filters, which isn't even directly in the call-path for projects_by_role is leaking and influencing the subsequent call to projects_by_role.

Actions #4

Updated by Jan K. about 7 years ago

We have the same problem I can confirm. See: Redmine 3.3.3 - missing issue table at project overview, ...

Actions #5

Updated by Leo Antunes about 7 years ago

For reference, the attached patches are the workarounds we're currently using (i.e.: definitely not solutions!).

The first one (redmine_issues_api_workaround.patch) is basically just what's mentioned in my second comment. The only side-effect I can imagine is showing the subproject filter option for projects which don't have subprojects. But maybe there are more, of course.

The second one (redmine_project_overview_workaround.patch) will completely ignore permissions for generating the tracker issue totals in the project overview page. This isn't a big problem for us, but it may be a problem for other people.

Actions #6

Updated by Serhiy Yefremenko about 7 years ago

Posted a new issue on this, added some details: #26376

Actions #7

Updated by Toshi MARUYAMA almost 7 years ago

  • Related to Defect #26376: Wrong issue counts and spent time on project overview added

Also available in: Atom PDF