Group Related Timeline Entries to Reduce Clutter

[PBruin]

The new timeline with detailed ticket information will show two entries when closing a ticket. The top entry will be:

Ticket #47 closed by PBruin
  Comment abcd

Next there is a entry:

Ticket #47 updated by PBruin
 resolution, status changed
 Comment abcd

This causes extra clutter on the timeline aspecially on a rss feed. I would prefer one entry like this:

Ticket #47 closed by PBruin
 resolution, status changed
 Comment abcd

[PBruin]

I am sad to see that the problem is getting worse. Now closing a ticket will create 4 entries on the timeline:

Ticket #44 (defect) close by PBruin
 Comment
Ticket #44 (defect) updated by PBruin
 Comment
Ticket #44 (defect) updated by PBruin
 resolution changed
Ticket #44 (defect) updated by PBruin
 status changed

It would be nice if this be included sooner then in version 1.0. This kind of duplicate info renders the timeline useless as it becomes difficult to read when there is some activity on tickets.

[Christian Boos]

[1705] fixes the bug you signaled in the previous comment.

This reverts the situation to the one you described originally in your problem report.

I'm not sure it is a real problem, though. If the duplicated information is not wanted, one could simply disable the Ticket changes events. The Ticket details will also report the new tickets, the reopened and closed tickets, among other detailed changes.

[PBruin]

I have created a little patch (maybe HACK) that will show one entry per ticket modification. This means a little hack as the ticket close and reopen entries are not displayed by TicketModule when showing ticket_details.
This is not neccesary as all information is shown by UpdateDetailsForTimeline.

Index: Ticket.py
===================================================================
--- Ticket.py	(revision 1718)
+++ Ticket.py	(working copy)
@@ -529,7 +529,9 @@
                         util.escape(summary), id, type, verbs[state], util.escape(author))
                 message = wiki_to_oneliner(util.shorten_line(message), self.env,
                                            db, absurls=absurls)
-                yield kinds[state], href, title, t, author, message
+                # only show the new tickets when showing details to prevent repeating entries on timeline
+                if not ('ticket_details' in filters and ( state == 'closed' or state == 'reopened')):
+                    yield kinds[state], href, title, t, author, message
 
     # Internal methods
 
@@ -698,28 +700,36 @@
             for time,id,type,field,oldvalue,newvalue,author,summary in cursor:
                 if not previous_update or (time,id,author) != previous_update[:3]:
                     if previous_update:
-                        updates.append((previous_update,field_changes,comment))
+                        updates.append((previous_update,field_changes,comment,action_text))
                     field_changes = []
                     comment = ''
+                    action_text = 'updated'
                     previous_update = (time,id,author,type,summary)
+                if field == 'status':
+                    action_text = newvalue
                 if field == 'comment':
                     comment = newvalue
                 else:
                     field_changes.append(field)
             if previous_update:
-                updates.append((previous_update,field_changes,comment))
+                updates.append((previous_update,field_changes,comment,action_text))
 
             absurls = req.args.get('format') == 'rss' # Kludge
-            for (t,id,author,type,summary),field_changes,comment in updates:
+            for (t,id,author,type,summary),field_changes,comment,action_text in updates:
                 if absurls:
                     href = self.env.abs_href.ticket(id)
                 else:
-                    href = self.env.href.ticket(id) 
-                title = 'Ticket <em title="%s">#%s</em> (%s) updated by %s' \
-                        % (util.escape(summary), id, type, util.escape(author))
+                    href = self.env.href.ticket(id)
+                title = 'Ticket <em title="%s">#%s</em> (%s) %s by %s' \
+                        % (util.escape(summary), id, type, action_text, util.escape(author))
                 message = ''
                 if len(field_changes) > 0:
                     message = ', '.join(field_changes) + ' changed.<br />'
                 message += wiki_to_oneliner(util.shorten_line(comment),
                                             self.env, db, absurls=absurls)
-                yield 'editedticket', href, title, t, author, message
+                if action_text == 'closed':
+                    yield 'closedticket', href, title, t, author, message
+                elif action_text == 'reopened':
+                    yield 'newticket', href, title, t, author, message
+                else:
+                    yield 'editedticket', href, title, t, author, message

[Christian Boos]

I tested the patch, it works well but I think it doesn't address the problem fully.

Let me explain: when I created the Ticket details filter (UpdateDetailsForTimeline timeline provider component), I designed it to show only additional informations, not as a replacement for TicketChanges.

So basically you had 2 situations that made sense:

• Trac behaves as in 0.8x:
  • forced behavior, by disabling the UpdateDetailsForTimeline component
  • chosen behavior, by disabling the Ticket details filter
• Trac shows all the information about tickets (#187):
  • Ticket changes filter enabled, Ticket details filter enabled

The problem was that you could still have the Ticket changes filter disabled and Ticket details filter enabled, which would show all the information but the newly created tickets…

And this is still the case with your patch, so I think a better solution would be:

• Ticket changes/off Ticket details/off:
  no problem here :)
• Ticket changes/on Ticket details/off:
  Show ticket created, closed and reopened (Trac < 0.9 behavior)
• Ticket changes/on Ticket details/on:
  Consolidated output, like what you end up showing with the above patch
• Ticket changes/off Ticket details/on:
  Here we have two possibilities:
  • consider that Ticket details/on implies Ticket changes/on, and force the above output
  • only show the ticket contributions and property changes excluding what would be shown by Ticket changes

I see arguments for both, but I would favor the second one, since it seems more correct on a theoretical point of view.

The first one would perhaps make sense if we could have another UI interface, like a Ticket information filter and three (mutually exclusive) level of details: None, State changes and All modifications, but that's currently not easily doable.

[Christian Boos]

The above solution (option only show the ticket contributions and property changes excluding what would be shown by Ticket changes) was implemented in [1724].