Issue visibility problems on 3.3.1
Hi,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.jsonwithout 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.
#2 Updated by Leo Antunes over 4 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
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
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 ;)
#3 Updated by Leo Antunes over 4 years ago
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
#5 Updated by Leo Antunes over 4 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.