Search Refactoring

One of the complaints I've heard regularly about Trac was it's not so useful search module. The usual answer was that we have nice ideas and plans for an AdvancedSearch, at some point in the future (1.0?).

But nevertheless, there are some simple steps that could be taken to incrementally improve the current situation, changes that don't require any kind of big redesign.

Issues

Ranking

The current situation is simply to find all the resources matching all the given search terms. It's either hit or miss, and the results are sorted in chronological order, most recent item first.

There are two things that could be done quite easily:

• give more importance to the resources that have many hits
• let the search source increase the relevance of a match if the match happens in some "search sensitive" area, like the summary or the keywords associated to that resource

While useful, the chronological ordering would gain to be replaced by a more useful relevance ordering, highest ranking results first.

Reuse of results

When you're searching for some tickets, you sometimes want to be able to restrict your search to either the opened or the closed tickets, or according to some other constraints on tickets. Since 0.10 (#2859), closed tickets are shown using the usual strike-through style and this is already helpful. But what would really be needed sometimes are the filtering capabilities of the ticket custom query module. In turn, it is inconvenient to start with a plain text search in the custom query. This has been discussed in #1329 (and the alternative #4824).

Direct access to resources by their numbers

While there's always been the possibility to use the "quickjump" facility in the search page, by writing any kind of TracLinks in the search field to go directly to the resource referred to by the link, there has been nevertheless constant request for the possibility to find resources by their numbers (see #1268 and numerous duplicates: #1644, #2919, #3419, #3856). There's also the need to take special care of short numbers (#4398) which are wrongly disqualified as search terms.

Proposed Solutions

(to be completed…)

Implemented so far:

• log:sandbox/search-api-tmp

Other minor glitches:

• #2561
• #2530, which could be addressed in the FieldRefactoring branch