Search results should emphasis closed tickets from other tickets

[Emmanuel Blot]

It would be nice if the search results reported the status of each ticket (closed or not) using the usual strike style.

[Christian Boos]

Implemented in r3000. I wonder if I should add the resolution information, too?

[Christian Boos]

Another place where chris' html.py++​ would be handy :)

api.py

@@ -197 +197 @@
         for summary,desc,author,keywords,tid,date,status in cursor:
             ticket = '#%d: ' % tid
             if status == 'closed':
-                ticket = util.Markup('<span style="text-decoration: '
-                                     'line-through">#%s</span>: ', tid)
+                ticket = util.html.SPAN(style="text-decoration: line-through",
+                                        title="closed as %s" % res)[ticket]
             yield (self.env.href.ticket(tid),
                    ticket + util.shorten_line(summary),
                    date, author,

[Emmanuel Blot]

I'm not sure to understand all the bits and pieces of the XHTML/CSS stuff here, but why are we forcing a style for closed tickets, instead of applying a class "closed" to the ticket header ?

Hard-coding the style here prevents from look customization, doesn't it ?

(Again, I may miss some important piece of info)

[Christian Boos]

Well, I did things that way in order to not disrupt too much the existing ISearchSource interface: The <a> element is currently produced by the Search component itself, out of the href and the text given by the ISearchSource. So there are basically two ways of producing a better output:

• Making the ISearchSource produce itself the <a>
• Make the ISearchSource return class information

Either way needs a modification of the return type of ISearchSource.get_search_results.

[Emmanuel Blot]

Ok, I got it. Thanks for the explanation

Maybe we should track somewhere this point for a future improvement ?

[Christian Boos]

As we've been talking for a long time about reimplementing the search facility for Trac 1.0, maybe we can gather the requirements for that new search facility in an AdvancedSearch page?

[Emmanuel Blot]

Yes, this would be probably easier to track the requirements

[Christian Boos]

Just to keep with this ticket's topic, an API change that would make sense would be to align the return type of ISearchSource.get_search_results to the one of ITimelineEventProvider.get_timeline_events, i.e.

• from (href, title, date, author, excerpt)
• to (kind, href, title, date, author, message)

Maybe we can do this for 0.11?