How to include changelog in ticket reports?

[p.schregle@…]

I want to create a ticket report that includes the full description as well as the changelog of a ticket.

I've tried the following report syntax:

SELECT p.value AS __color__,
   t.milestone AS __group__,
   (CASE status 
      WHEN 'closed' THEN 'color: #777; background: #ddd; border-color: #ccc;'
      ELSE 
        (CASE owner WHEN '$USER' THEN 'font-weight: bold' END)
    END) AS __style__,
   id AS ticket, summary, component, status, 
   resolution,version, severity, priority, owner,
   changetime AS modified,
   time AS _time,reporter AS _reporter,
   description AS _description_
  FROM ticket t,enum p
  WHERE p.name=t.priority AND p.type='priority'
  ORDER BY (milestone IS NULL), milestone DESC, (status = 'closed'), 
        (CASE status WHEN 'closed' THEN modified ELSE -p.value END) DESC

which works as I'd like it but does only include the ticket description originally provided with the ticket, not the changes made to the ticket afterwards.

[Christopher Lenz]

This is the wrong forum for asking such questions. Please ask on the MailingList or the IrcChannel.

[cboos@…]

Sorry for re-opening this ticket, but I'm curious: why such a request for support couldn't better be handled by Trac itself?

I see several advantages to that approach, because:

• On the IrcChannel, you don't necessarily find someone able/willing to invest some time to help you at the time you're asking the question. It's maybe OK for quick short questions, but even then the answer is lost for all but the few who are on the channel at that time…
• On the MailingList, by definition you're not inside Trac, and you loose the whole integration-by-wiki idea of Trac.

Of course, you can say that a support request is neither a bug nor a feature request, that there's no point in linking such a ticket to a milestone, etc. But nevertheless:

• The ticket interface makes it really possible to use it as a question/answer tool. Most of the properties really make sense for that (see this very ticket).
• That How To? information can be easily retrieved by using the full text search or the query search facilities
• it is also easier to refer to this information if it is stored this way than it would be if it were in a discussion thread on the mailing list
• To distinguish a support request ticket from a bug report, one could use a prefix in the summary (e.g. [Q], like some people are using [patch] or [merge] for patches) or better, use a special category for that (e.g. Support Request) (yet another advertising for my ticket category patch :) #919)

[p.schregle@…]

Furthermore I do think it's either a bug or a feature request, because I've been unable to find a (documented) way to do this.

[Matthew Good <trac@…>]

Yes, I agree with cmlenz. At least for now, support questions are easier to deal with via IRC or email. Just like many open source projects have separate "user" and "dev" mailing lists, the Trac MailingList reaches a lot of users who may have encountered a similar problem, but many of these users won't read through the tickets to see what's being done on the development side.

I can see some potential benefits for Trac supporting support requests directly (e.g. marking as "resolved"), but for now on the Trac project site I think the tickets should be used for documenting requested changes to the code.

Useful information gleaned from support requests can (should) be documented on the project Wiki.