Macros in ticket titles display verbatim on detail page, but are stripped in timeline

[Tim Hatch <trac@…>]

For example, make a ticket called A[[BR]]B. This will show up normally on the ticket detail, as 8 characters. It will show up as three on the timeline page — A B (I guess Genshi is turning the \n into a space in its normalization process. The titles display as expected (8 characters) on the query pages too, and in searches.

I think this is due to the wikify() call in templates/timeline.html which is quite helpful most of the time, however some things don't allow wiki markup, like ticket titles. Perhaps a flag on timeline events could specify whether event.message should be displayed verbatim in the template? If there's desire to get this changed, I can come up with a patch.

[Tim Hatch <trac@…>]

Patch against trunk

[Tim Hatch <trac@…>]

I've added a patch that properly displays ticket titles in the timeline view, by putting the plain string into TimelineEvent.markup rather than TimelineEvent.message. I also fixed resolutions that had characters in them needing to be escaped like a<span>, by removing the Markup() call and letting it be treated as text. There was some weird business with assigning a null string along different branches, which I also simplified (this is a judgement call for you guys, it's not related to this ticket and I don't grok why it was written the way it was).

[Christian Boos]

Ok, I applied most of the suggested changes in r4290. However, the escape is now done by proper use of the html() Element builder and the comment needs to be wikified.

Thanks for the patch anyway!

[Tim Hatch <trac@…>]

Actually, there's a regression with your fix in r4290. The previous version had (type) verb in the event title and the new one has (verb).

[Tim Hatch <trac@…>]

trac/ticket/web_ui.py

@@ -304 +304 @@
                 return None
             kind, verb = status_map[status]
             title = html('Ticket ', html.em('#', id, title=summary),
-                         ' (', verb, ')')
+                         ' (', type, ') ', verb)
             ticket_href = req.href.ticket(id)
             if cid:
                 ticket_href += '#comment:' + cid

[Christian Boos]

ok …

[Christian Boos]

Fixed in r4294. I took this opportunity to reintroduce my old preferred way of displaying the ticket type information… feedback welcomed ;)

[Christopher Lenz]

Replying to cboos:

Fixed in r4294. I took this opportunity to reintroduce my old preferred way of displaying the ticket type information… feedback welcomed ;)

I'm still -1 on that presentation. “Enhancement #123 created” or “Bug #123 updated” makes no sense IMO. If anything, it should be “Enhancement request” and “Bug report”, respectively. But I'd strongly prefer we just stick to the term “Ticket” everywhere to have a consistent and simple terminology, and use the type as an extra annotation.

[Christian Boos]

Well, then the ticket type names could be updated to be Enhancement Request and Bug Report respectively. Task is already OK.

The point is that the generic Ticket term doesn't buy you anything, it only wastes precious space in the title line. And having the type relegated at the end of the line makes it barely useful, as you don't notice it immediately. If I understand correctly, your main concern is to keep the term Ticket so that we have a consistent terminlogy, so a compromise could be to write Bug Report ticket #123 updated by ….

In the future, I'd like to emphasize the role of ticket types, going in the direction of having special templates (#4044) and special fields (#2464) for each type.

Compare the following options:

1. Ticket #123 (enhancement) created
2. Enhancement Request #123 created
3. Enhancement Request ticket #123 created
4. enhancement ticket #123 created

When "scanning" a timeline, your attention is drawn by the first term, so with 1. you don't really notice the (enhancement) annotation, that's why I'm looking for a better alternative.

[Christopher Lenz]

Replying to cboos:

The point is that the generic Ticket term doesn't buy you anything, it only wastes precious space in the title line.

I don't agree. Obviousy, it identifies what kind of resource you're dealing with (a ticket vs a changeset vs …)

And having the type relegated at the end of the line makes it barely useful, as you don't notice it immediately.

I must say I don't see this entire argument about why the type classification is supposed to be any more important than the other classifiers. Often, I could care less whether something is an enhancement request or a bug report, but care more about what the component, milestone, or version is (or any other field). For me, the type is just another classification among many. Now, I can understand why some may consider it somehow more important, which is why I've not objected to putting it in parenthesis all over the place. But I'm strongly -1 at this point on making it any more prominent than it already is.

I have another problem with emphasizing the ticket type to the point of replacing the term “Ticket” with the type: the type can easily change in the life cycle of a ticket. Ticket #32 is always Ticket #32. Task #32, on the other hand, could be Enhancement request #32 tomorrow, and then Task #32 next week.

Using the ticket type to identify the resource also seems to apply that every type has it's one set of unique IDs. I.e. that Task #32 is actually a different resource than Enhancement request #32.

If I understand correctly, your main concern is to keep the term Ticket so that we have a consistent terminlogy, so a compromise could be to write Bug Report ticket #123 updated by ….

Ticket #123 (bug) is a lot cleaner IMO.

Can you please back out the timeline change?

[Christian Boos]

Ok, so let me try to come to a common understanding:

• The ticket type as it exists now can be seen as just another "information" added to a ticket
• The ticket type as I envisioned it at the beginning was a cheap way of getting another resource type, basically similar to a ticket, but in the end, with different capabilities (different fields, different workflows, etc.). That's also why I referred to #2464 and #4044.

Obviously, there are some issues with overloading the ticket resource, the main one being what you described above: a ticket type can change over its lifetime. This introduces various issues at the datamodel and UI levels.

So I think than rather to try to bend the current ticket into a kind of generic thing, we/I should rather concentrate on having an extensible resource model, so that we could have real resources types for Bug Reports, Enhancements Requests, etc.

Then, the ticket type as it exists now can be either phased out, or kept for those wanting "light" ticket type (i.e. no more than what it is now, a qualifier among others).

With real resources, Bug Report #12 will always remain Bug Report #12, and if it's actually not a bug, but an enhancement request, then it should be closed with a moved to Enhancement Request #34 resolution status (for example).

At that point, this could probably deserve a prominent place in the timeline ;)

In the meantime, well, hm, r4304:4305 …