Add review requested filter on pull request overview

[jpraet]

Fixes #13682

This adds a filter on the pull request overview pages that allows you to find the pull requests that are requesting your review.

• Is the name "Review Requested" for the filter OK? On GitHub it is called "Review Requests". Most clear is probably something like "Requesting your review", which is consistent in phrasing with the existing "Mentioning you" filter. What do you think?
• Review requests records are not deleted once the review has taken place, so in the query I had to add a subselect to only take the last review record into account. I worry a bit about performance impact? Is there a better way?
• With [API] Add more filters to issues search #13514 the existing "created", "assigned" and "mentioned" issue filters were made available through the API as well. Would you like me to add API support for the "review_requested" filter as well?

[codecov-io]

Codecov Report

Merging #13701 (85d2668) into master (872d308) will increase coverage by 0.00%.
The diff coverage is 67.96%.

@@           Coverage Diff           @@
##           master   #13701   +/-   ##
=======================================
  Coverage   41.84%   41.85%           
=======================================
  Files         744      744           
  Lines       79689    79714   +25     
=======================================
+ Hits        33347    33361   +14     
- Misses      40843    40849    +6     
- Partials     5499     5504    +5     

Impacted Files	Coverage Δ
routers/api/v1/repo/issue.go	49.55% <0.00%> (-0.30%)	⬇️
routers/user/home.go	59.27% <0.00%> (-0.44%)	⬇️
models/issue.go	56.77% <64.17%> (-0.42%)	⬇️
routers/repo/issue.go	38.24% <93.10%> (+0.06%)	⬆️
modules/git/tree_nogogit.go	60.86% <0.00%> (-8.70%)	⬇️
modules/indexer/stats/db.go	60.00% <0.00%> (-8.00%)	⬇️
modules/avatar/avatar.go	50.00% <0.00%> (-4.77%)	⬇️
modules/git/repo_language_stats_nogogit.go	57.44% <0.00%> (-4.26%)	⬇️
models/error.go	38.49% <0.00%> (-0.49%)	⬇️
models/gpg_key.go	53.90% <0.00%> (+0.57%)	⬆️
... and 8 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 872d308...85d2668. Read the comment docs.

[silverwind]

This will need a rebase now after #13594.

Edit: actually no, that part was not consolidated.

[lynxplay]

Is there any update on this PR? Our team would really appreciate the change for the main workflow of our release cycle.

[jpraet]

TODO: also return review requests for teams you belong to.

When looking at the code for team review requests, I notice that when a user submits a review with status Reject or Approve, any existing review requests for the teams the user belongs to are removed. So I do wonder why we wouldn't also remove review requests for the user there? It would remove the need for these subselects in all the queries. Is there a reason we need to keep these superseded user review request records?

[jpraet]

This is done. Added team review requests to the filter + a refactoring to remove the code duplication in the issue filtering conditions.

[lunny]

Fixes #13682

This adds a filter on the pull request overview pages that allows you to find the pull requests that are requesting your review.

• Is the name "Review Requested" for the filter OK? On GitHub it is called "Review Requests". Most clear is probably something like "Requesting your review", which is consistent in phrasing with the existing "Mentioning you" filter. What do you think?

I like Review Requested which is shorter than "Requesting your review"

• Review requests records are not deleted once the review has taken place, so in the query I had to add a subselect to only take the last review record into account. I worry a bit about performance impact? Is there a better way?

Maybe we should have another PR to delete the review requests when user reviewed or PR merged/closed ?

• With [API] Add more filters to issues search #13514 the existing "created", "assigned" and "mentioned" issue filters were made available through the API as well. Would you like me to add API support for the "review_requested" filter as well?

Yes, please!!!

[jpraet]

• Review requests records are not deleted once the review has taken place, so in the query I had to add a subselect to only take the last review record into account. I worry a bit about performance impact? Is there a better way?

Maybe we should have another PR to delete the review requests when user reviewed or PR merged/closed ?

This can indeed be done in another PR. It would also require a data migration to delete the obsoleted review requests.

• With [API] Add more filters to issues search #13514 the existing "created", "assigned" and "mentioned" issue filters were made available through the API as well. Would you like me to add API support for the "review_requested" filter as well?

Yes, please!!!

Already done in 92c25fa. So as far as I'm concerned this PR is ready for review and merge.

[6543]

@jpraet can you update the branch ;)