Global issues search

[lunny]

Currently we have issues where you can find all your related issues. But when the issues are too much, maybe you want to search them.

[kolaente]

It probably is very inperformant, to go through every issue when you issue a search, so: should we cache? (And how?)

Caching would probably mean to put every issue in a redis/memstore with everything that belongs to it.

[stevegt]

Caching may be needed in some cases, but I wouldn't bother with it for a first implementation. A gitea instance run by an individual or small organization may not have enough issues in their db to cause a problem. If performance is still a concern, make global search an admin tool only, or add a config option to turn the global search feature off.

In my own case, global issue search is one of the first things I went looking for, which led me here. Seems like a gitea admin would need at least a global view of issues, similar to the global view of repos in /admin. Among other things, this would allow them to see how well gitea is being adopted so they can help bring project teams up to speed.

[stevegt]

#3841 (possible dup) discusses how the web frontend for this might look.

[scullhead]

Here is my content from the issue #3841

• Gitea version (or commit ref): 1.4.0+3-g641d481
• Git version: 2.7.4
• Operating system: Ubuntu 16.04.4 LTS
• Database (use [x]):
  • PostgreSQL
  • MySQL
  • MSSQL
  • SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL)
  • No
  • Not relevant

Description

When you are on the "issues" tab of a repository you have a search input field where it is possible to search for a text in all issues of this repo.

When you klick on "Issues" in the global navigation menu of gitea it shows a list of all issues from all repositories (if they are public).
It would be very useful if there was also a search input field to search over all public issues.

[stevegt]

Here's a possible workaround until global issues search is available, but it only really works for new installs and internal teams: Our local Gitea install so far hosts dozens of projects and growing. Early on, we realized that we need to be able to see who is working on what in some global way to keep interns from running out of things to do. ;-)

As a workaround, we've wound up filing all issues for all projects in one general/issues repository instead of in their proper repos -- not great, but at least it gives us a quick way to see issue lists by assignee.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

[lunny]

We need a search result UI design.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

[jag3773]

Signalling that this is a desired feature by many of our users. We are working on several projects that make heavy use of issues and it would be really handy to be able to search across all of them.

[lunny]

Where is the best place to put the search box?

[guillep2k]

/issues sounds good.
EDIT: the first comment has a good picture of what could it look like.

[lunny]

@guillep2k That design is good but I don't think that's the best place. A search box on /issues will let you think that the search scope is all issues related you but not all the sites.

[guillep2k]

@guillep2k That design is good but I don't think that's the best place. A search box on /issues will let you think that the search scope is all issues related you but not all the sites.

They will be related to me because they will be the issues I can see. e.g. "Issues you have access to".

Check this picture; adding "All issues" can help convey the idea.

[lunny]

Then the repositories on the left corner when you checked all repository maybe a large list.

[jag3773]

@lunny That's exactly why a global search is an essential feature!

[bhalbright]

I'm probably missing the whole picture, but in #7901 I am attempting to add an endpoint to search issues across repositories (i.e. the repositories the user has access to). Just wanted to comment because perhaps it could be of use here. However, I put the endpoint under repos like for example: /api/v1/repos/issues/search?q={query}

[guillep2k]

@bhalbright Perhaps it should not be under /api/v1/repos if it's not searching inside a particular repo? @lafriks ?

[bhalbright]

@guillep2k I think I did it because all the "issues" api endpoints seemed to already be under /repos but I can see where this one might be debatable. For example from the swagger doc (the first in the list is the one I added in the #7901 PR)

[bhalbright]

Just dropping a note that I'm going to work on an attempt at this based on the ui design by @scullhead
and @guillep2k

[lunny]

@bhalbright The permission check with pagnation is something we need pay attention to.

[6543]

I think a global issue search should be here: