Modify

Opened 5 years ago

Closed 2 years ago

#5892 closed defect (wontfix)

[patch] unique timestamps needed for use with MasterTicketsPlugin

Reported by: abbywinterscom Owned by: farialima
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 abbywinterscom 5 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 5 years ago by abbywinterscom

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 5 years ago by hoff.st@…

  • Summary changed from timestamp uniqueness in combination with MasterTicketsPlugin to [patch] unique timestamps needed for use with MasterTicketsPlugin

comment:2 Changed 4 years ago by farialima

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 4 years ago by hasienda

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 2 years ago by farialima

  • Resolution set to wontfix
  • Status changed from new to closed

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

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
Author


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

 
Note: See TracTickets for help on using tickets.