Allow searching issues by ID

[silkentrance]

When you are entering a number in the issue search, you likely want the issue with the given ID (code internal concept: issue index).
As such, when a number is detected, the issue with the corresponding ID will now be added to the results.

Fixes #4479

[delvh]

Erm… It looks like you mixed up concepts if I see that correctly:
An issue ID is instance-wide unique and never shown in the UI. You can only retrieve it from the API.
The issue index on the other hand is unique per repository and probably what you intended as that's what you can call as …/issues/2 for example.
But I do understand the confusion, if I didn't know about the underlying data model, I would have called it id as well.

[wxiaoguang]

Actually I have a different idea for fixing the problem.

If an number is inputed, I think we should just query it directly from database and fill the result into the list.

Then everything works well and it doesn't need to depend on the indexer, and we could make the match issue at the top as the first one (it really helps for end users to quickly select it)

[silkentrance]

Erm… It looks like you mixed up concepts if I see that correctly: An issue ID is instance-wide unique and never shown in the UI. You can only retrieve it from the API. The issue index on the other hand is unique per repository and probably what you intended as that's what you can call as …/issues/2 for example. But I do understand the confusion, if I didn't know about the underlying data model, I would have called it id as well.

Oh, yes, currently they are in sync on my system 😄

I will fix that and also change it so that it will go the fast route via the index and db indexer. @wxiaoguang @delvh

[silkentrance]

I need to wrap my head around the tests first but I think that it will be rather easy to do.

[silkentrance]

I am at a loss here. While it compiles, lints and works just fine, the tests fail with some error message that I cannot figure out.

https://github.com/go-gitea/gitea/actions/runs/9668323949/job/26672235178?pr=31479#step:8:185

I noticed that the web route for the issue search will query for the repository ids that are accessible by the user, so I added the repository ids to the test cases as well, reasoning that passing in an empty array would be the cause, but it wasn't.

https://github.com/go-gitea/gitea/pull/31479/files#diff-da412f571b8d5ab9187ee252f9a0e71f0908915eec4bfd51ea584fd209b22ccdR91

[wxiaoguang]

Hmm, maybe we could try a simpler approach (avoid touching too many if):

1. Existing code keeps as-is
2. Insert a new if: if input is number { query exactly one issue from db and insert into result list at the beginning }
3. De-duplicate the result list

2 and 3 could be merged into one new function.

Then we only need to add a new function, it's easier to test and no need to handle various indexer cases. Then we only need to test the newly added function by some mocked data, no need to touch existing search indexer cases.

[wxiaoguang]

If you don't mind, I could work on this PR and make some edits

[silkentrance]

Hmm, maybe we could try a simpler approach (avoid touching too many if):

1. Existing code keeps as-is
2. Insert a new if: if input is number { query exactly one issue from db and insert into result list at the beginning }
3. De-duplicate the result list

2 and 3 could be merged into one new function.

Then we only need to add a new function, it's easier to test and no need to handle various indexer cases. Then we only need to test the newly added function by some mocked data, no need to touch existing search indexer cases.

This would break current behaviour, as the search is across all repositories that the user has access to, so searching for an issue by keyword will bring up issues from both repository a and b. And so must the search for the index number.

As for the failing test: like I said i must first get my head around the way that the test suite works incl. also the library being used...

[wxiaoguang]

Sorry but maybe I haven't fully understand the problem. Could the "dependency dropdown" add other repository's issue as a dependency? IIRC it only support adding current repository's issues?

[silkentrance]

@wxiaoguang Found it, it is the sql query that included a query for index, which is actually a keyword in sqlite. My oh my, without any stracktraces available, this was hard to find 😁
But doing some googling for syntax error near index did the trick...

Shouldn't xorm take care of that? I have used the universal(?) escape using double quotes, e.g. "\"index\"", so this should work with all supported RDMBS. Or is there a better way to do it?
Maybe consider migrating issue.index to some other name that does not collide with a keyword from any of the supported RDBMS?
E.g. lid for local id or even rlid for repo local id.

[silkentrance]

Sorry but maybe I haven't fully understand the problem. Could the "dependency dropdown" add other repository's issue as a dependency? IIRC it only support adding current repository's issues?

Not with the version I am currently working on. It will give me results from multiple repositories I am the owner of. Not so shure, whether this applies to non admin/owner users...

But looking at the code at https://github.com/coldrye-collaboration/gitea/blob/fix/gh4479-issue-dependency-select-broken/routers/web/repo/issue.go#L2600, it seems as if it fetches all repositories that are accessible to the user.
See also https://github.com/coldrye-collaboration/gitea/blob/fix/gh4479-issue-dependency-select-broken/routers/web/repo/issue.go#L2549.

[silkentrance]

Hmm, maybe we could try a simpler approach (avoid touching too many if):

1. Existing code keeps as-is
2. Insert a new if: if input is number { query exactly one issue from db and insert into result list at the beginning }
3. De-duplicate the result list

2 and 3 could be merged into one new function.

Then we only need to add a new function, it's easier to test and no need to handle various indexer cases. Then we only need to test the newly added function by some mocked data, no need to touch existing search indexer cases.

If you are worried about the cyclomatic complexity, be assured, that the new code is not a hotspot 😀

I think that keeping the SearchOptions.Index an optional and populating that optional in the root indexer should be kept, allowing you the possibility to use the indexers in case that a prefix based search on the index number is required.
This, of course can also be achieved with the db indexer, however, "casting" the index number into a string and then doing a like search on it is rather expensive.

For now, the optimal route will be taken via the db indexer.

[silkentrance]

I have squashed the changes into a single commit.