Edgewall Software
Modify

Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#11288 closed defect (fixed)

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

Reported by: Jun Omae Owned by: Jun Omae
Priority: low Milestone: 1.0.2
Component: ticket system Version: 1.0-stable
Severity: normal Keywords: batch-modify
Cc: Ryan J Ollos Branch:
Release Notes:

Fix duplicated ticket ids for batchmodify timeline events

API Changes:
Internal Changes:

Description

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.

Attachments (0)

Change History (16)

comment:1 by Jun Omae, 7 years ago

Keywords: batch-modify added

comment:2 by Ryan J Ollos, 7 years ago

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):

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:

Last edited 7 years ago by Ryan J Ollos (previous) (diff)

comment:3 by Jun Omae, 7 years ago

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

    diff --git a/trac/ticket/web_ui.py b/trac/ticket/web_ui.py
    index e3f1ada..69f0e9f 100644
    a b class TicketModule(Component):  
    296296                    FROM ticket_change tc
    297297                        INNER JOIN ticket t ON t.id = tc.ticket
    298298                            AND tc.time>=%s AND tc.time<=%s
    299                     ORDER BY tc.time
     299                    ORDER BY tc.time, tc.ticket
    300300                    """ % (ts_start, ts_stop)):
    301301                if not (oldvalue or newvalue):
    302302                    # 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

comment:4 by Peter Suter, 7 years ago

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

comment:5 by Jun Omae, 7 years ago

Milestone: next-dev-1.1.x1.0.2
Version: 1.1.1dev1.0-stable

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

comment:6 by Peter Suter, 7 years ago

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!

Last edited 7 years ago by Jun Omae (previous) (diff)

comment:7 by Jun Omae, 7 years ago

Owner: set to Jun Omae
Release Notes: modified (diff)
Status: newassigned

comment:8 by Jun Omae, 7 years ago

Resolution: fixed
Status: assignedclosed

Committed in [12201] and merged into trunk in [12202].

comment:10 by Ryan J Ollos, 7 years ago

I see a lot of duplicate RSS feed entries (and duplicated tickets in each RSS message) from t.e.o since it is still running a rather old version of 1.1.2dev (from 15 June 2013).

Last edited 7 years ago by Ryan J Ollos (previous) (diff)

comment:11 by Peter Suter, 7 years ago

Oops, I mistakenly assumed t.e.o. already runs this fix "because 1.0.2 < 1.1.2", but that's of course nonsense. Sorry for the noise.

comment:12 by Ryan J Ollos, 7 years ago

It would be great to get t.e.o upgraded though, so we can confirm some of the fixes that have been put in place.

comment:13 by Christian Boos, 7 years ago

Agreed… it's done now (r12584).

comment:14 by Ryan J Ollos, 7 years ago

Cc: Ryan J Ollos added

It looks like there might be a problem with the repository caching. I committed [12585:12587], but the changesets are not shown yet in the repository browser.

Last edited 7 years ago by Ryan J Ollos (previous) (diff)

comment:15 by Jun Omae, 7 years ago

milestone:1.1.2 said This Trac instance is using Trac 1.1.2dev-r11682, Genshi 0.7dev-r1134 and Babel 0.9.6. I just modified it to r12584.

in reply to:  14 comment:16 by Christian Boos, 7 years ago

Replying to rjollos:

It looks like there might be a problem with the repository caching. I committed [12585:12587], but the changesets are not shown yet in the repository browser.

Right, there was, and it's fixed now (we used to also have the 1.0-stable's trac-admin notify the 1.1 envs of added changesets, which no longer works now that there's been an environment upgrade).

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain Jun Omae.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from Jun Omae to the specified user.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.