Defect #25828
open
Issue visibility problems on 3.3.1
0%
Description
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.
Files
Related issues
Updated by Leo Antunes over 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 ;)
Updated by Leo Antunes over 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.
Updated by
Updated by Leo Antunes over 7 years ago
- File redmine_issues_api_workaround.patch redmine_issues_api_workaround.patch added
- File redmine_project_overview_workaround.patch redmine_project_overview_workaround.patch added
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.
Updated by Serhiy Yefremenko over 7 years ago
Posted a new issue on this, added some details: #26376
Updated by Toshi MARUYAMA over 7 years ago
- Related to Defect #26376: Wrong issue counts and spent time on project overview added