Include public repos in doer's dashboard for issue search

[wolfogre]

It will fix #28268 .

⚠️ BREAKING ⚠️

But need to give up some features:

However, such abandonment may fix #28055 .

Backgroud

When the user switches the dashboard context to an org, it means they want to search issues in the repos that belong to the org. However, when they switch to themselves, it means all repos they can access because they may have created an issue in a public repo that they don't own.

It's a confusing design. Think about this: What does "In your repositories" mean when the user switches to an org? Repos belong to the user or the org?

Whatever, it has been broken by #26012 and its following PRs. After the PR, it searches for issues in repos that the dashboard context user owns or has been explicitly granted access to, so it causes #28268.

How to fix it

It's not really difficult to fix it. Just extend the repo scope to search issues when the dashboard context user is the doer. Since the user may create issues or be mentioned in any public repo, we can just set AllPublic to true, which is already supported by indexers. The DB condition will also support it in this PR.

But the real difficulty is how to count the search results grouped by repos. It's something like "search issues with this keyword and those filters, and return the total number and the top results. Then, group all of them by repo and return the counts of each group."

Before #26012, it was being done in the DB, but it caused the results to be incomplete (see the description of #26012).

And to keep this, #26012 implement it in an inefficient way, just count the issues by repo one by one, so it cannot work when AllPublic is true because it's almost impossible to do this for all public repos.

gitea/modules/indexer/issues/indexer.go

Lines 318 to 338 in 1bfcdee

	// CountIssuesByRepo counts issues by options and group by repo id.
	// It's not a complete implementation, since it requires the caller should provide the repo ids.
	// That means opts.RepoIDs must be specified, and opts.AllPublic must be false.
	// It's good enough for the current usage, and it can be improved if needed.
	// TODO: use "group by" of the indexer engines to implement it.
	func CountIssuesByRepo(ctx context.Context, opts *SearchOptions) (map[int64]int64, error) {
	if len(opts.RepoIDs) == 0 {
	return nil, fmt.Errorf("opts.RepoIDs must be specified")
	}
	if opts.AllPublic {
	return nil, fmt.Errorf("opts.AllPublic must be false")
	}
	repoIDs := container.SetOf(opts.RepoIDs...).Values()
	ret := make(map[int64]int64, len(repoIDs))
	// TODO: it could be faster if do it in parallel for some indexer engines. Improve it if users report it's slow.
	for _, repoID := range repoIDs {
	count, err := CountIssues(ctx, opts.Copy(func(o *internal.SearchOptions) { o.RepoIDs = []int64{repoID} }))
	if err != nil {
	return nil, err
	}

Give up unnecessary features

We may can resovle TODO: use "group by" of the indexer engines to implement it, I'm sure it can be done with Elasticsearch, but IIRC, Bleve and Meilisearch don't support "group by".

And the real question is, does it worth it? Why should we need to know the counts grouped by repos?

Let me show you my search dashboard on gitea.com.

I never think the long repo list helps anything.

And if we agree to abandon it, things will be much easier. That is this PR.

TODO

I know it's important to filter by repos when searching issues. However, it shouldn't be the way we have it now. It could be implemented like this.

The indexers support it well now, but it requires some frontend work, which I'm not good at. So, I think someone could help do that in another PR and merge this one to fix the bug first.

Or please block this PR and help to complete it.

Finally, "Switch dashboard context" is also a design that needs improvement. In my opinion, it can be accomplished by adding filtering conditions instead of "switching".

[wxiaoguang]

I do not need the left "repo list", so I have no objection.

But it doesn't seem good to backport such a breaking change.

[GiteaBot]

I was unable to create a backport for 1.21. @wolfogre, please send one manually. 🍵

go run ./contrib/backport 28304
...  // fix git conflicts if any
go run ./contrib/backport --continue

[6543]

if you use it less like an "issue search" and more like an "issue dashboard" the repo filter IS quite usefull ...

some could argue that the UX was bad ... yes. I'll open a new issue to bring "repo filters" back .. -> #31578