Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issue totals are wrong when filtering by team #19636

Closed
jpraet opened this issue May 6, 2022 · 6 comments · Fixed by #19652
Closed

Issue totals are wrong when filtering by team #19636

jpraet opened this issue May 6, 2022 · 6 comments · Fixed by #19652
Labels
issue/regression Issue needs no code to be fixed, only a description on how to fix it yourself type/bug
Milestone

Comments

@jpraet
Copy link
Member

jpraet commented May 6, 2022

Description

The issue totals for "Assigned to you", "Created by you" and "Mentioning you" are incorrect in the statistics when filtering on team, when the current filter is "In your repositories".

image

When selecting another filter, they are correct:

image

I recently upgraded from 1.16.4 to 1.16.7, and I believe it may be a regression in #18916.

Gitea Version

1.16.7

Can you reproduce the bug on the Gitea demo site?

Yes

Log Gist

No response

Screenshots

No response

Git Version

No response

Operating System

No response

How are you running Gitea?

docker

Database

No response

@jpraet jpraet added type/bug issue/regression Issue needs no code to be fixed, only a description on how to fix it yourself labels May 6, 2022
@Gusted
Copy link
Contributor

Gusted commented May 6, 2022

Yup seems to be a regression from #18916. Not really able to debug this, but if anyone wants to give a try models.SearchRepositoryCondition(repoOpts) seems to be the faulty here, it's returning the incorrect repoID's.

@wxiaoguang
Copy link
Contributor

Maybe it's caused by that the RepoCond is applied too early.

		if filterMode == models.FilterModeYourRepositories {
			statsOpts.RepoCond = models.SearchRepositoryCondition(repoOpts)
		}
		// GetUserIssueStats needs to count all kinds of issues like YourRepositoriesCount / AssignCount / CreateCount
		// however, the statsOpts.RepoCond has been limited by FilterModeYourRepositories
		issueStats, err = models.GetUserIssueStats(statsOpts)

@jpraet
Copy link
Member Author

jpraet commented May 7, 2022

// Detect when we only should search by team.
if opts.User == nil {
statsOpts.UserID = 0
}

By setting the UserID to 0 the stats for assigned / created / mention cannot work.

@Gusted
Copy link
Contributor

Gusted commented May 8, 2022

Maybe it's caused by that the RepoCond is applied too early.

		if filterMode == models.FilterModeYourRepositories {
			statsOpts.RepoCond = models.SearchRepositoryCondition(repoOpts)
		}
		// GetUserIssueStats needs to count all kinds of issues like YourRepositoriesCount / AssignCount / CreateCount
		// however, the statsOpts.RepoCond has been limited by FilterModeYourRepositories
		issueStats, err = models.GetUserIssueStats(statsOpts)

Yes good catch. The overall issueStats should be independent of the filterMode 😅.

By setting the UserID to 0 the stats for assigned / created / mention cannot work.

Why not? It only makes sense for 'created', as you cannot create a issue as team. But you can mention/assign a team to a issue/PR. It actually seems like providing a 'created' item here is not correct.

Gusted pushed a commit to Gusted/gitea that referenced this issue May 8, 2022
- Don't use hacky solution to limit to the correct RepoID's, instead use
current code to handle these limits. The existing code is more correct
than the hacky solution.
- Resolves go-gitea#19636
@Gusted
Copy link
Contributor

Gusted commented May 8, 2022

#19652 refactors the code a bit and fixes the issue.

Gusted pushed a commit to Gusted/gitea that referenced this issue May 8, 2022
- Backport go-gitea#19652
  - Don't use hacky solution to limit to the correct RepoID's, instead use current code to handle these limits. The existing code is more correct than the hacky solution.
  - Resolves go-gitea#19636
@jpraet
Copy link
Member Author

jpraet commented May 8, 2022

By setting the UserID to 0 the stats for assigned / created / mention cannot work.

Why not? It only makes sense for 'created', as you cannot create a issue as team. But you can mention/assign a team to a issue/PR. It actually seems like providing a 'created' item here is not correct.

Ah, but this is not how this used to work before. With the dropdown box you can select to filter by team repositories:

image

  • "Assigned to you" shows the issues/pulls assigned to you in those team repo's
  • "Created by you" shows the issues/pulls you created in those team repo's
  • "Mentioning you" shows the issues/pulls mentioning you in those team repo's
  • "Review requested" shows the pulls in those team repo's that request your review

wxiaoguang pushed a commit that referenced this issue May 16, 2022
- Backport #19652
  - Don't use hacky solution to limit to the correct RepoID's, instead use current code to handle these limits. The existing code is more correct than the hacky solution.
  - Resolves #19636
wxiaoguang pushed a commit that referenced this issue May 16, 2022
- Don't use hacky solution to limit to the correct RepoID's, instead use
current code to handle these limits. The existing code is more correct
than the hacky solution.
- Resolves #19636
- Add test-case
@lunny lunny added this to the 1.16.8 milestone May 16, 2022
AbdulrhmnGhanem pushed a commit to kitspace/gitea that referenced this issue Aug 24, 2022
- Don't use hacky solution to limit to the correct RepoID's, instead use
current code to handle these limits. The existing code is more correct
than the hacky solution.
- Resolves go-gitea#19636
- Add test-case
@go-gitea go-gitea locked and limited conversation to collaborators May 3, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
issue/regression Issue needs no code to be fixed, only a description on how to fix it yourself type/bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants