Specifically the wiki search results should look better, but let's see how much improvement we can get through the generic search result template. E.g. https://sourceforge.net/p/allura/wiki/search/?q=faq A few suggestions
<hr>
for something betterHere's a mockup of how https://sourceforge.net/p/allura/wiki/search/?q=faq could look: http://screencast.com/t/06dC4NjT60
Tickets: #2835
Tickets: #4097
Tickets: #4807
Tickets: #4816
Tickets: #5686
Diff:
Diff:
Originally by: wellread1
It seems that in the last 1.5 years there has been no action to address the known lack of ability sort answer sets chronologically.
Please take a look at the KeePass forum https://sourceforge.net/p/keepass/discussion/. The forum software was updated in Nov 2012 and searching has been nearly useless since. Old, irrelevant hits are mixed in and listed high on the search results.
Try a quick search, you will find many hits on the first results page that are over 5 years old and pertain to obsolete versions of KeePass.
Originally by: wellread1
Thank you for describing the workaround (via allura-users-help) that allows a user to add a date filter to a search, e.g. the following search will find posts mentioning "install" and posted since Feb 1 2013:
install AND mod_date_dt:[2013-02-01T00:00:00Z TO *]
Diff:
Diff:
Created:
If something would require solr upgrade, I'll create separate ticket for that.
Related
Tickets:
#2835Closed #287 (Search: re-style generic search template).
allura:je/42cc_2835
I'll be trying to review these quickly since there are a lot of parts for this ticket, hopefully will make it all go smoother.
The template changes look good. There are placeholders so I can't merge it yet. If we get to a point where some parts of this ticket are completely done, I'll merge them before the rest.
One more thing: can we make this template apply to the "search whole project" page too? E.g. /p/testproject/search?q=test&history=False
Ok, I'll remove placeholders when closing a next ticket.
Yes, we can. I'll create another ticket for that if you don't mind. I think it'll require some cosmetic work (handling paging, new search options, etc)
Closed #288 (Search: improve wiki search).
allura:je/42cc_2835
For wiki search I've changed solr parser to 'dismax'. It better for user-generated queries, it matches on multiple fields, with some smart analyzers and tokenizers of user input. Standard parser matches only on
text
(that's why there was code to append all other fields to it). I've made it match ontitle
andtext
fields, seems like this is the only fields we should match on things like wiki pages and comments.Also, I've made some changes in the indexation of wiki pages. I've added the
title
field as a copy oftitle_s
field that already presented in the index (my first try was to match ontitle_s
field, but it turned out that solr doesn't apply all the fancy analyzers and tokenizers to it, so matches were not always relevant with this approach).I've left indexation of tickets as it was (appending all the field into
text
), 'cause new indexation breaks some searches with standard solr parser.I think we should change other apps' searches to this approach (use 'dismax' parser).
However, ticket's search seems to be a special case. It uses ability to match on specific fields a lot ('status:open and labels:42cc' and queries like that). With 'dismax' parser we're losing this ability, so ticket's search should be separate (actually, it is now).
I've removed placeholders, so you can merge it to master. Wiki now uses a better search. All other apps use a new template, but with old solr parser.
Also, if you don't like how artifact type is placed next to title in search results, you can revert commit
332a696
:)solarize()
, hard-coding a type check for 'ticket' is a little ugly. Could theTicket.index()
method build the 'text' key itself? Or, another option would be to have an artifact attribute called something likeindex_all_fields
and itArtifact
sets it to False and Ticket sets it to True. Thensolarize()
would check for that instead.title_s
seems a little odd, but if you say it's necessary I'll take your word for it :) Can you add a comment in the main Artifact.index method explaining why it has to be duplicated?After those are addressed, I think I'll be ready to merge the current progress.
Additional things going forward:
I think we can just add a url param to use standard parser. But how it would be accessible from UI? Maybe another group of radio buttons (like for project/app search) or something?
I've been thinking of it too, and now it's seems to me that it's not necessary. I think I'll try to get rid of
title_s
for all artifacts (maybe except for ticket, since we're not changing them)I'll create a new ticket on our side to deal with issues that prevents you from merging the current progress.
Yep, I've been thinking about this approach too. I think we'll deal with this in #292 (Search: check that other apps working with new generic search template) after all tweaks for wiki work fine.
For wiki pages it's a little trickier than for forums. I think it would be a new ticket too.
Created:
Related
Tickets:
#2835I'd only use the standard parser for the label-specific search link for now. We may want an option for it on the main search form at some point, but lets keep it simple for now and not put it there yet.
Ok. We'll add a url parameter to use standard parser, without any UI for it.
Thanks for such immediate response :)
Closed #303.
je/42cc_2835
I guess, you should be able to merge current progress to master now :)
Closed #290 (Search: content preview and highlight matches)
This requires changes in solr config (
text
field should be stored). See diff forsolr_config/
branch:
je/42cc_2835_content_preview
Closed #289 (Search: sort results)
77b869d..112fb4a t289_sort_search -> je/42cc_2835_content_preview