-
-
Notifications
You must be signed in to change notification settings - Fork 5.7k
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 by Issue Index #19646
Conversation
Add issue ID to found issues if it is a string
mysql integration test fails - could be an elastic search related issue :/ |
problem: test dont show errors!!! (https://drone.gitea.io/go-gitea/gitea/54666/2/14) |
Isn't we can get the issues via index from databases? Why we need this PR? |
At that time (I reviewed the original PR), I think that changing the search logic is more heavy than adding a search field. For example, if you input "12345", it might be an issue index, it might be an keyword to be searched, so putting it into the search engine is quite simple. Indeed, this PR is a nice to have, not a must. We can teach users to input the issue index in browser's address bar directly too, it depends how we think. So, merging it or not, either is fine for me. I just took the original PR as an example, even if we think a PR is not suitable, we had better tell the contributors at the first time, it could make contributors feel better. |
@@ -244,6 +247,7 @@ func (b *BleveIndexer) Search(ctx context.Context, keyword string, repoIDs []int | |||
for _, repoID := range repoIDs { | |||
repoQueriesP = append(repoQueriesP, numericEqualityQuery(repoID, "RepoID")) | |||
} | |||
index, _ := strconv.ParseInt(keyword, 10, 64) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we need to check if index > 0 to decide to if we need search the field.
When you input |
Yep, that's also a solution. The PR author didn't accept it before. Refer to the original PR, it has been discussed. |
Since there is no new requirement for this feature, and there is still divergence on it. I would propose to convert it to a draft, leave it as it is, until there is some new thoughts or new requirements about it. (maybe by some RFC in the future). I don't think we should merge it just because someone has approved it at the moment. |
Will be replaced by #24479 |
commits taken from #17929