Changes between Version 6 and Version 7 of SearchRefactoring
- Timestamp:
- Mar 1, 2023, 5:03:45 PM (14 months ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
SearchRefactoring
v6 v7 1 1 = Search Refactoring = 2 2 3 One of the complaints I've heard regularly about Trac was its not so useful search module. 4 The usual answer was that we have nice ideas and plans for an AdvancedSearch, at some point in the future ([milestone:1.0]?). 5 6 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. 3 One of the complaints voiced regularly about Trac is its not so useful search module and as a result nice ideas and plans for an AdvancedSearch have been drafted. But nevertheless, there are some simple steps that could be taken to incrementally improve the search capability, changes that don't require any kind of big redesign. 7 4 8 5 == Issues == 9 6 === Ranking === 10 7 11 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 sortedin chronological order, most recent item first.8 The current situation is simply to find all the resources matching all the given search terms. The results are in chronological order, most recent item first. 12 9 13 10 There are two things that could be done quite easily: … … 18 15 19 16 === Reuse of results === 17 20 18 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 [milestone: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. 21 19 This has been discussed in #1329 (and the alternative #4824). 22 20 21 === Direct access to resources by their numbers === 23 22 24 === Direct access to resources by their numbers === 25 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. 23 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 requests for the possibility to find resources by their numbers (see #1268 and its duplicates: #1644, #2919, #3419, #3856). There's also the need to take special care of short numbers (#4398) which are incorrectly qualified as search terms. 26 24 27 25 == Proposed Solutions == … … 58 56 - rebase the above work (i.e. diff:trunk@5689//sandbox/search-api-tmp@5690) on recent trunk, using the new `ITimelineEventProvider` style, with a `render_search_result` method added to `ISearchProvider` (see r6141). 59 57 60 Other minor glitches: 61 - #2561 62 - #2530, which could be addressed in the FieldRefactoring branch 63 - #7069 58 Other minor glitch: [[TicketQuery(id=7069)]]
