Opened 15 years ago
Last modified 14 months ago
#8436 new defect
search results won't show matches from ticket comments
Reported by: | Christian Boos | Owned by: | |
---|---|---|---|
Priority: | normal | Milestone: | next-stable-1.6.x |
Component: | search system | Version: | 0.11-stable |
Severity: | minor | Keywords: | |
Cc: | Ryan J Ollos | Branch: | |
Release Notes: | |||
API Changes: | |||
Internal Changes: |
Description
Noticed while testing the case sensitivity of search: tickets can be correctly retrieved when looking for words written in ticket comments, but the excerpt shown in the search results will never show the actual matches.
Attachments (0)
Change History (8)
comment:1 by , 15 years ago
comment:2 by , 10 years ago
Milestone: | next-minor-0.12.x → next-stable-1.0.x |
---|
comment:3 by , 10 years ago
Hello,
we're using Trac since about 8 years and are very happy with it. In the last times more and more questions about long ago project decisions come up. Regularly i'm searching (using custom query) the ticket database for answers. Yesterday i'm stumbled over the fact that ticket comment are not searched.
It would be of great value for us if this would be possible.
Seems that i'm lucky and this issue is already known.
+1 for having an enhancement for 1.0.x.
Best reards,
Klaus
comment:4 by , 10 years ago
Cc: | added |
---|
comment:5 by , 9 years ago
Owner: | removed |
---|
comment:6 by , 8 years ago
Milestone: | next-stable-1.0.x → next-stable-1.2.x |
---|
Moved ticket assigned to next-stable-1.0.x since maintenance of 1.0.x is coming to a close. Please move the ticket back if it's critical to fix on 1.0.x.
comment:7 by , 5 years ago
Milestone: | next-stable-1.2.x → next-stable-1.4.x |
---|
This seems to be due to the fact that some results match the comments to a ticket and some would match the actual ticket description or summary.
I think that a provable solution would be to join all of the text, description newvalue and comments into one big cblob that then would be shortened by search.api.shorten_result.
This, however, may lead to a massive performance hit with ticket searches.
Perhaps the best solution would be to further refine the ISearchSource implementation in ticket.web_ui which then would split the existing single query into multiple queries. This however, will also degrade overall search performance.
Any ideas?