プロジェクト

全般

プロフィール

Vote #78466

未完了

Issue visibility problems on 3.3.1

Admin Redmine さんが約4年前に追加. 約4年前に更新.

ステータス:
New
優先度:
通常
担当者:
-
カテゴリ:
Issues_2
対象バージョン:
-
開始日:
2022/05/09
期日:
進捗率:

0%

予定工数:
category_id:
2
version_id:
0
issue_org_id:
25828
author_id:
260438
assigned_to_id:
0
comments:
7
status_id:
1
tracker_id:
1
plus1:
0
affected_version:
closed_on:
affected_version_id:
122
ステータス-->[New]

説明

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


journals

Seems to be something going on "here":https://github.com/redmine/redmine/blob/3.3.1/app/helpers/queries_helper.rb#L216,L221.
--------------------------------------------------------------------------------
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:
<pre>
- subprojects = project.descendants.visible.to_a
+ subprojects = project.self_and_descendants.visible.to_a
</pre>

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 ;)
--------------------------------------------------------------------------------
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@.
--------------------------------------------------------------------------------
We have the same problem I can confirm. See: message#52816
--------------------------------------------------------------------------------
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.
--------------------------------------------------------------------------------
Posted a new issue on this, added some details: #26376
--------------------------------------------------------------------------------

--------------------------------------------------------------------------------


related_issues

relates,Closed,26376,Wrong issue counts and spent time on project overview

Admin Redmine さんが約4年前に更新

  • カテゴリIssues_2 にセット

他の形式にエクスポート: Atom PDF

いいね!0
いいね!0