Closing milestone and retargeting tickets to another does not show in change history

[mlists at bigrideau.com]

When I close a milestone and select "retarget open tickets" the tickets are successfully retargeted, however the change in milestone is not reflected in the ticket change history.

[Christian Boos]

Right, this would be a nice thing to have. However, the design is not trivial if we don't want to duplicate the change metadata everywhere.

Related to #1890 (change metadata) and #525 (batch modifications).

[anonymous]

Pardon my ignorance, but given that a milestone change on its own is reflected in the ticket history could this same api not be called when a ticket is retargeted?

[Christian Boos]

As I said, it's not trivial if we don't want to duplicate the metadata. Conversely, it is trivial if we decide to duplicate the change information everywhere…

The real problem is that doing a big bunch of inserts (one entry recording the change metadata, either directly or indirectly a la #1890) will likely expose the milestone retarget operation to locking issues (see #3446).

[Emmanuel Blot]

Replying to cboos:

The real problem is that doing a big bunch of inserts (one entry recording the change metadata, either directly or indirectly a la #1890) will likely expose the milestone retarget operation to locking issues (see #3446).

Would it be possible, as a workaround, to acquire and release a DB lock for each updated ticket? Retargetting ticket is an operation that occurs only a few times so a slow execution is not a big issue IMHO. OTOH, managing metadata may not be implemented in the next months… so a temp. workaround may be a useful solution.

[mlists at bigrideau.com]

Has my vote. You are correct that at least in our usage model this would happen at most once per week so speed is not of the essence.

[Christian Boos]

#5897 mentions the same problem but for milestone renames instead of retarget after close.

[mape <th07@…>]

This kind of silent changes really confuses up my ​TimeVisualizerPlugin, which draws burndown graphs from ticket, ticket_custom and especially from ticket_change. If history is not properly written, the graph gets messed and can't be reliably used to trace projects (scrum burndown graph).

I'm quite new to trac. Is there any other cases when ticket_change gets outdated? Quicly I could name these:

• retarget open tickets when closing milestone #5658
• rename milestone #5897
• my guess: using webadmin to change component or milestone names

It would feasible to minimize db altering with SQL and use APIs whenever possible. And then APIs should respect history (as proposed in ​TracObjectModelProposal. I strongly support idea of having unique (and constant) id for objects as proposed in ​DataModel, which would fix renaming issues.

I have now a bad feeling that it is too easy mess up my graph with trac (or 3rd components). Maybe the original idea of having ticket listener and writing own log would have been better - even it has many other drawbacks. Of course ticket listener itself would not be enough - I would need also milestone and component listeners…

[Christian Boos]

#7615 was closed as duplicate.

One of the issue here is how to store the change efficiently for all the tickets (see related discussion on this topic in #1890). Same problematic applies to #525 as well.

Also I think that adding a fixed comment like "milestone was renamed" or "retargeted after closing milestone", depending on the situation would be nice. In the future, this might even contain a link to the milestone version which triggered the change (for now milestone data is unversioned).