changetime is not updated when editing comments

[txcraig@…]

We use the XmlRpc API ticket.getRecentChanges to query on changetime > (yesterday) to keep tabs on recently modified tickets. If a new comment is added to a ticket, the changetime is updated correctly and we get the ticket in the list of changed tickets.

However if a comment is edited, the changetime remains the same as before the comment edit. This causes us to miss tickets that have been updated with new (possibly critical) information.

I considered whether editing a comment truly constitutes a modification to the ticket. I figured that if adding a comment justifies updating ticket changetime, then editing a comment should too.

I also looked for a [ticket] option on whether to update changetime on comment edit (similar to the batch mod plugin), but I did not see one.

Here is a sample TracReport which shows tickets modified in the last 24 hours:

SELECT id AS ticket, 
summary, 
datetime(changetime/1000000, 'unixepoch')  AS LastModified,
description AS _description,
status
FROM ticket t
WHERE  LastModified >= datetime('now','-24 hours')
ORDER BY time DESC

To repro, just modify a ticket in that list, and you can see the changetime does not get updated.

Looking at ticket/model.py, seems like adding something similar to this at the end of modify_comment might do the trick:

when_ts = to_utimestamp(datetime.now(utc))
cursor.execute("UPDATE ticket SET changetime=%s WHERE id=%s",
                           (when_ts, self.id))

While I can patch this myself for my instance, I would be very interested in seeing this get into a release so that others using the XmlRpc API would get the expected result. Thanks in advance for considering this defect.

[Remy Blank]

That sounds like a good idea.

[Remy Blank]

Update changetime when editing a ticket comment.

[Remy Blank]

Does 10086-update-changetime-r10665.patch​ solve the issue for you?

[txcraig]

I applied the patch to my local installation and it is working as expected. Thanks, you guys are the best!

[Remy Blank]

Patch applied in [10678].

[AdrianFritz]

Patched on Trac 0.12. Editing an existent comment keeps the same time on timeline. I think should have an entry (on timeline) for every action. This looks like strange. Not good for traceability at least.

[Remy Blank]

No, comment editing is meant to be used to make small corrections to comments, like fixing formatting, forgotten WikiFormatting or spelling errors, not major edits. As such, it's a good thing they don't appear in the timeline. For longer edits, you should be adding a new comment instead.

Updating the "last changed" time is useful to detect any modification to a ticket through an API, as explained in the description.

[AdrianFritz]

Thank you. Then is working as expected. Please, guide me were I should document this (if not already there).

[Remy Blank]

It's true that the guide doesn't mention ticket comment editing at all. A small paragraph under TracTickets#ChangingandCommentingTickets would be most welcome, thanks!

[AdrianFritz]

Reviewed TracTickets@57. Please, could you check it?

[Remy Blank]

Great, thanks! I just made a few cosmetic changes in the next version.

[AdrianFritz]

I got lost. Can you, please, clarify me. According to this paragraph: "All edits (field changes, new comments, comment edits) update the "last changed" time of the ticket. This allows easily detecting changes to a ticket." This I can see / chek. But when comment editing, the timeline view has no time update (it just updates the comment and keeps the same time as the comment was entered at the first time). Is it that the expected behavior?

[Remy Blank]

Replying to AdrianFritz:

I got lost. Can you, please, clarify me.

Let me try again:

• All changes (field changes, new comments, comment edits) update the "last changed" time of the ticket. No exceptions.
• The timeline shows ticket creations, field changes and new comments, but not comment edits.
• The time shown in the timeline is the time of the respective change. In the case of comments, this is the time when the comment was first added, not the time of the last comment edit.

This allows easily detecting changes to a ticket.

In retrospect, this sentence doesn't help at all, so I'll remove it.

[Christian Boos]

My take on the topic…

Replying to AdrianFritz:

I got lost. Can you, please, clarify me.

Well, currently we just decided to not show those ticket comment edits in the timeline (see the "properties like _comment{n} are hidden" comment in source:trunk/trac/ticket/web_ui.py​).

You have two situations. If you correct your comment only moments later after you saved it, then we chose to not show two edit comments events, only the original one but with the latest content. But if the edit happened much later, then it would indeed be worth having a new "event" informing of that change, something like "comment:13 edited (diff)" with the diff link leading to the diff view of that change.

It's just a bit difficult to find a behavior which looks appropriate in all situations. The situation is a bit similar to what happens with "minor edits" for Wiki pages. In #38, we discussed at length this tradeoff, not risking to hide critical update information on one side and not cluttering too much the timeline on the other side.