Opened 14 years ago
Last modified 14 years ago
#9539 new defect
Attachments do not change Last Modified Time
Reported by: | Owned by: | ||
---|---|---|---|
Priority: | normal | Milestone: | next-major-releases |
Component: | attachment | Version: | 0.12-stable |
Severity: | major | Keywords: | attachment file last modified time RPC |
Cc: | kageex@… | Branch: | |
Release Notes: | |||
API Changes: | |||
Internal Changes: |
Description
Adding attachments/files to a ticket does not change the value of Last Modified Time. I am using the RPC API to find recently updated Tickets. Since attachments do not change the modified time value, I never know if a ticket had new attachments.
Attachments (0)
Change History (3)
comment:1 by , 14 years ago
Milestone: | → next-major-0.1X |
---|
follow-up: 3 comment:2 by , 14 years ago
Thank you for responding so quickly. It is true that attachments do not modify a ticket, but neither do comments. I can post a comment without changing any values of the ticket yet this will still be logged as a "modifcation" and update the last modified value accordingly. How is this different than an attachment?
What do you mean by "no more a matching attachment event"? I don't see where an attachment can simply be deleted without a trace.
comment:3 by , 14 years ago
Replying to kageex@…:
What do you mean by "no more a matching attachment event"? I don't see where an attachment can simply be deleted without a trace.
But that's exactly what happens: when one deletes an attachment, it's exactly as if that attachment had never been added. Again, I don't say it's "good", it's just the way it is currently implemented (since 0.8).
Welcome to the concept of "transient" changes ;-)
As for one attachments don't modify the ticket itself, for another the attachments can be deleted or replaced anytime without leaving a trace, we didn't record attachment events as ticket changes, so far. Instead, we collect the attachments events and merge them with "proper" permanent ticket changes when displaying the ticket history, but we don't number them (see the #comment:n ids, attachments events don't have them).
As your use case is certainly a valid one, suggestions for improvements are welcomed. For example, we could leave a permanent record of the changes (in
ticket_change
), and simply omit to show them when there's no more a matching attachment event, in case of a later deletion or replacement.