Incorrect title and link for batch-modify events in timeline rss

[Jun Omae]

I've updated tickets using batch-modify feature at 2013-08-30T19:38:30+09:00. The title and link of the event are correct in timeline page. However, the title and link are incorrect in timeline rss. The ticket id are repeated in the title and link.

In timeline page:

• title: Tickets #5499,​8813,​10740,​11219 batch updated by jomae
• link: http://trac.edgewall.org/query?id=5499%2C8813%2C10740%2C11219

In timeline rss:

• title: Tickets #5499,​8813,​10740,​10740,​11219,​11219 batch updated
• link: http://trac.edgewall.org/query?id=5499%2C8813%2C10740%2C10740%2C11219%2C11219

    </item><item>
      <title>Tickets #5499,​8813,​10740,​10740,​11219,​11219 batch updated</title>
      
        <dc:creator>jomae</dc:creator>

      <pubDate>Fri, 30 Aug 2013 10:38:30 GMT</pubDate>
      <link>http://trac.edgewall.org/query?id=5499%2C8813%2C10740%2C10740%2C11219%2C11219</link>
      <guid isPermaLink="false">http://trac.edgewall.org/query?id=5499%2C8813%2C10740%2C10740%2C11219%2C11219/1377859110243015</guid>
      <description></description>
      <category>batchmodify</category>
    </item><item>

I don't know whether or not we can reproduce with 1.0-stable.

[Ryan J Ollos]

I've noticed this issue on t.e.o as well. Possibly related, my RSS reader (feedly) shows repeated entries for a batch modification change. Here is a recent example (timeline:2013-10-09T22:47):

• 19 hrs ago: Tickets #4231,​​4503,​​4997,​​5097,​​5246,​​5640,​​6007,​​6143,​​7116,​​7343,​​7343,​​8269,​​8289,​​8336,​​8336,​​9215,​​9976,​​10727,​​11026 batch updated
• 1 day ago: Tickets #4231,​​4503,​​4997,​​5097,​​5246,​​5640,​​5640,​​6007,​​6007,​​6143,​​6143,​​7116,​​7343,​​8269,​​8289,​​8336,​​9215,​​9976,​​10727,​​11026 batch updated
• 1 day ago: Tickets #4231,​​4503,​​4997,​​5097,​​5246,​​5640,​​6007,​​6143,​​7116,​​7343,​​8269,​​8289,​​8336,​​9215,​​9215,​​9976,​​10727,​​11026 batch updated
• 4 days ago: Tickets #4231,​​4503,​​4997,​​5097,​​5246,​​5640,​​6007,​​6143,​​6143,​​7116,​​7343,​​8269,​​8289,​​8336,​​9215,​​9976,​​10727,​​11026,​​11026 batch updated
• 5 days ago: Tickets #4231,​​4503,​​4997,​​5097,​​5246,​​5640,​​6007,​​6143,​​7116,​​7343,​​7343,​​8269,​​8289,​​8289,​​8336,​​9215,​​9976,​​10727,​​11026 batch updated

There are more entries going back farther. Note that each RSS event has different duplicate tickets.

I haven't been able to reproduce the issue in a development environment. Looking at the code, it is rather strange that the timeline and RSS entries would be different, since each is generated by calling event.render:

• tags/trac-1.1.1/trac/timeline/templates/timeline.html@:47,49#L40​
• tags/trac-1.1.1/trac/timeline/templates/timeline.rss@:20,22-23​

[Jun Omae]

I suppose that the query in produce_ticket_change_events() should be the following at source:tags/trac-1.0.1/trac/ticket/web_ui.py@:294-299,305#L290​.

trac/ticket/web_ui.py

@@ -296 +296 @@
                     FROM ticket_change tc
                         INNER JOIN ticket t ON t.id = tc.ticket
                             AND tc.time>=%s AND tc.time<=%s
-                    ORDER BY tc.time
+                    ORDER BY tc.time, tc.ticket
                     """ % (ts_start, ts_stop)):
                 if not (oldvalue or newvalue):
                     # ignore empty change corresponding to custom field

The produce_ticket_change_events() iterates ticket.id and time for each ticketmodify. However, the query sorts only ticket_change.time. If the query returns the following, the same ticket id is returned more than once.

ticket      time              author      field       oldvalue    newvalue
----------  ----------------  ----------  ----------  ----------  ----------
3           1382348110040725  jun66j5     cc                      jun66j5
5           1382348110040725  jun66j5     cc                      jun66j5
6           1382348110040725  jun66j5     cc                      jun66j5
3           1382348110040725  jun66j5     comment     2
5           1382348110040725  jun66j5     comment     5
6           1382348110040725  jun66j5     comment     3

[Peter Suter]

Interesting. Nice catch. I don't understand why only RSS is affected though.

[Jun Omae]

The issue depends on range for ticket_change.time and database backend. If the range is narrow, it rarely happens. Proposed fix and unit tests can be found in [1e458e62f/jomae.git].

If without the fix, TicketModule.get_timeline_events() for batch-modify returns duplicated ticket.id.

$ PYTHONPATH=. ~/venv/py25/bin/python trac/ticket/tests/batch.py
.........................F
======================================================================
FAIL: Regression test for #11288
----------------------------------------------------------------------
Traceback (most recent call last):
  File "trac/ticket/tests/batch.py", line 301, in test_timeline_events
    self.assertEqual(ids, sorted(batch_ev[3][0]))
AssertionError: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17,
18, 19, 20] != [1, 1, 1, 1, 2, 2, 2, 2, 3, 3, 3, 3, 4, 4, 4, 4, 5, 5, 5, 5,
6, 6, 6, 6, 7, 7, 7, 7, 8, 8, 8, 8, 9, 9, 9, 9, 10, 10, 10, 10, 11, 11, 11,
11, 12, 12, 12, 12, 13, 13, 13, 13, 14, 14, 14, 14, 15, 15, 15, 15, 16, 16,
16, 16, 17, 17, 17, 17, 18, 18, 18, 18, 19, 19, 19, 19, 20, 20, 20, 20]

----------------------------------------------------------------------
Ran 26 tests in 1.553s

[Peter Suter]

Ah, so it only occurs more often on RSS, because the default daysback parameter is larger there. But Timeline page can also trigger this (scroll down to August 30.) depending on daysback and from and bad luck / database backend.

Thanks for looking into this!