-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
Fix issue overview for teams #19652
Fix issue overview for teams #19652
Conversation
Gusted
commented
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 Issue totals are wrong when filtering by team #19636
- 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
- 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
Codecov Report
@@ Coverage Diff @@
## main #19652 +/- ##
=======================================
Coverage ? 47.35%
=======================================
Files ? 957
Lines ? 133318
Branches ? 0
=======================================
Hits ? 63132
Misses ? 62544
Partials ? 7642
Continue to review full report at Codecov.
|
There's quite a few IN SELECTs in there and whilst the SQL is correct I'm wondering if we might want to use a few JOINS instead of chains of IN SELECTs - however perhaps we should consider that for another PR. |
Feel free to do it. This is a plain copy-paste of the SQL that is otherwise used by the function( |
A subquery maybe faster than join in modern databases. |
Could we have a test which could reproduce #19636 ? So that we can prevent to repeat the problem. |
Added it: 50e61af Quite annoying to debug the SQL statements to only realize that rows on the test database is set to |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems good. If I understand correctly, the major change between this one and the code before the last PR is : Check if the user is in the owner team of the organisation.
, and fixes the bug caused by opts.RepoCond = models.SearchRepositoryCondition(repoOpts)
Yes, this caused my previous PR to be incorrect, as I thought this was already implemented so I adjusted the code until it had that result(but was actually incorrect).
Yup, by using the already supported TeamID option. |
* giteaofficial/main: Fix issue overview for teams (go-gitea#19652) Fix nodeinfo caching and prevent NPE if cache non-existent (go-gitea#19721) Update go-chi/cache to utilize Ping() (go-gitea#19719) Disable blank issues (go-gitea#19717) clarify what session provider 'db' does (go-gitea#19713) [skip ci] Updated translations via Crowdin
- 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