Modify

Opened 8 years ago

Closed 5 years ago

#5892 closed defect (wontfix)

[patch] unique timestamps needed for use with MasterTicketsPlugin

Reported by: Abbywinters.com WebDev Owned by: François Granade
Priority: normal Component: TicketImportPlugin
Severity: normal Keywords: patch
Cc: Trac Release: 0.11

Description

When TicketImportPlugin is used with MasterTicketsPlugin there can be a problem is 2 tickets are imported/updated that both are "blocking" the same ticket. This is because the MasterTicketsPlugin will, as a side effect, update the "blockedby" field of the parent ticket. This means that 2 rows in the same import spreadsheet may cause 2 side-effect updates to a single ticket. This means that (ticket,time,field) will not be unique for these 2 changes in the ticket_change table.

In order to rectify this, we should use a different time stamp (increment by 1 second) as when_ts for each row in the spreadsheet. This is the "standard" work around for bulk updates in Trac, because it is the only way to make each row emulate a separate change submission.

I've attached a simple patch to address this issue.

Attachments (1)

talm_import_timestamp.patch (562 bytes) - added by Abbywinters.com WebDev 8 years ago.
after processing a spreadsheet line, increment the internal timestamp so the next line is inserted with a timestamp of 1 second later

Download all attachments as: .zip

Change History (5)

Changed 8 years ago by Abbywinters.com WebDev

Attachment: talm_import_timestamp.patch added

after processing a spreadsheet line, increment the internal timestamp so the next line is inserted with a timestamp of 1 second later

comment:1 Changed 8 years ago by Steffen Hoffmann

Summary: timestamp uniqueness in combination with MasterTicketsPlugin[patch] unique timestamps needed for use with MasterTicketsPlugin

comment:2 Changed 8 years ago by François Granade

I understand your problem, but I'm hesitating to accept the patch: it may mean that we create/update tickets *in the future* which may cause problems, no ?

What about rather *decreasing* the time by one second ? Would that work for you ?

comment:3 Changed 8 years ago by Steffen Hoffmann

Since Trac 0.12dev recently moved to microsecond POSIX time stamps for similar reasons I suggest, to not fix, or at least do it with the proposed backwards counting for <= 0.11 only. Trac 0.12 is about to be released and will fix this for sure, nothing needed on plugin's side.

comment:4 Changed 5 years ago by François Granade

Resolution: wontfix
Status: newclosed

I believe we can mark this ticket as won't fix, since the issue doesn't occur on 0.12 (release already some times ago...)

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain François Granade.
The resolution will be deleted.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.