Review requests do not honour user blocking, unlike assignment

[torjan0]

Gitea Version

1.27.3

What happened?

Blocking a user does not prevent them from requesting a review from you. Assigning is blocked, review requesting is not.

validateAssignee rejects the blocked case as its first check:

// services/issue/assignee.go:168
func validateAssignee(ctx context.Context, issue *issues_model.Issue, doer, assignee *user_model.User) error {
	if user_model.IsUserBlockedBy(ctx, doer, assignee.ID) {
		return user_model.ErrBlockedUser
	}

Its structural sibling isValidReviewRequest at services/issue/review_request.go:45 has no block check. grep -c Block services/issue/review_request.go returns 0.

Review-request validation checks account type, read access, self-review, and the requester's authority, but does not consult the personal block. The local public-repository tests confirmed a persisted review request, an in-app notification row, and a review-requested queue entry while the block remained active.

Four review paths carry no block check:

1. Individual review request, API routers/api/v1/repo/pull_review.go:911 and web routers/web/repo/pull_review.go:431. Reproduced.
2. Team review request, API :936 and web :399, which notifies a blocker who is merely a member of the named team. Reproduced.
3. Reviewers supplied at pull request creation, services/pull/pull.go:174-180. Observed in source, not exercised.
4. Automatic CODEOWNERS requests, services/issue/pull.go:146-165, which call the model add functions directly and bypass the validators. Observed in source, not exercised.

Separately, creating a block does not clear review requests that already exist. The cleanup transaction at services/user/block.go:78-131 unfollows, unstars, unwatches, unassigns, removes collaborations and cancels transfers, but does not touch reviews or notifications, so a request made before the block survives it.

Reproduction

1. As alice, block bob.
2. As bob, create a public repository and open a pull request in it.
3. As bob, request a review from alice, through the API or the web UI. It succeeds.
4. As bob, try to assign alice on the same pull request. It returns 403 with user is blocked.
5. As alice, observe the notification and the entry in /pulls?type=review_requested&state=open.

Local tests on 1.27.3 checked the stored review and in-app notification rows and the authenticated review-requested queue. Individual and team requests were tested through API and web handlers. Creation-time and CODEOWNERS paths were inspected in source only. Email delivery was not tested.

What did you expect to happen?

That a review request from a blocked user is rejected the same way an assignment is, given that the documentation places blocking under Access Control and lists assignment and mention notifications among the interactions it prevents.

I have not assumed what the fix should be. The team and CODEOWNERS paths raise a design question worth deciding before anyone writes a patch: whether an automatic CODEOWNERS request should honour a personal block at all, and whether a team request should be filtered per member or rejected outright.

How are you running Gitea?

Official 1.27.3 linux-amd64 binary, SQLite, on Linux. Local test instance bound to loopback with synthetic accounts.

Note

This issue concerns unwanted in-app notifications and review-queue entries. The local tests established no unauthorized data access, privilege gain, or service disruption. Please tell me if you would rather have had it privately.