-
-
Notifications
You must be signed in to change notification settings - Fork 5.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow searching issues by ID #31479
base: main
Are you sure you want to change the base?
Allow searching issues by ID #31479
Conversation
2e7aa6c
to
7bfe539
Compare
Erm… It looks like you mixed up concepts if I see that correctly: |
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) |
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 |
7bfe539
to
ba448d2
Compare
I need to wrap my head around the tests first but I think that it will be rather easy to do. |
ba448d2
to
604c69e
Compare
75361d4
to
51149a0
Compare
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. |
Hmm, maybe we could try a simpler approach (avoid touching too many
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 don't mind, I could work on this PR and make some edits |
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... |
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? |
@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 😁 Shouldn't xorm take care of that? I have used the universal(?) escape using double quotes, e.g. |
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. |
51149a0
to
be7db18
Compare
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. For now, the optimal route will be taken via the db indexer. |
@wxiaoguang And yes, tests are still failing because the order of the issue ids is always different, working on that. The web route uses |
be7db18
to
ef44af2
Compare
@wxiaoguang I think that everything is working now and that the code is minimally intrusive. I am not liking the index thing, though and strongly believe that the issue.index should be renamed as xorm is not taking care of escaping the reserved keyword. And I am not so sure whether the elephants in the room, namely mssql or oracledb will support the double quote escape. Not so sure about mysql/mariadb, either. |
@wxiaoguang applied. thanks. |
c6972bb
to
e546736
Compare
91f3344
to
09a846f
Compare
64750fd
to
488e0db
Compare
- Use backticks instead of double quotes Co-authored-by: wxiaoguang <[email protected]>
488e0db
to
9c464e2
Compare
I have squashed the changes into a single commit. |
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