When updating ticket should take in-reply-to -header into account

[eero.afheurlin@…]

It would be nice to check for the in-reply-to and references headers to see which comment this is a reply to since trac (0.11) notifications add this information to headers and when using the web interfacy "reply" button trac has these nice arrows for quick reference.

[eero.afheurlin@…]

In fact this might be a impossible (at least in any sensible manner), upon reading the code more thoroughly it seems the message-id:s are generated via hashing and thus the comment id is not sensibly retvievable (we could make educated guesses about the preimage based on data in ticket_change and the ticket id we already resolved and then calculate hashes from our guesses and compare but that's not sensible)

[bas]

Did you find a solution

[eero.afheurlin@…]

I thought of alternate approach, which probably will be workable: in the plugin API override the default message-id generator method with our own which generates message-id where the comment id is readable.

I'll try to whip up some proof-of-concept code tomorrow.

[bas]

Just a remark when i update a ticket via the web-interface and the notification is send. Is still possible to reply on the notification mail or must we also replace the message-id generator?

[bas]

yes if the subject line is intact

[bas]

Just have some new inspiration, maybe we can just use the same syntax as in trac-post-commit-script? If we have some text in the body, ala:

# It searches commit messages for text in the form of:
#   command #1
#   command #1, #2
#   command #1 & #2
#   command #1 and #2
#
# Instead of the short-hand syntax "#1", "ticket:1" can be used as well, e.g.:
#   command ticket:1
#   command ticket:1, ticket:2
#   command ticket:1 & ticket:2
#   command ticket:1 and ticket:2
#
# In addition, the ':' character can be omitted and issue or bug can be used
# instead of ticket.
#
# You can have more then one command in a message. The following commands
# are supported. There is more then one spelling for each command, to make
# this as user-friendly as possible.
#
#   close, closed, closes, fix, fixed, fixes
#     The specified issue numbers are closed with the contents of this
#     commit message being added to it.
#   references, refs, addresses, re, see
#     The specified issue numbers are left in their current status, but
#     the contents of this commit message are added to their notes.
#
# A fairly complicated example of what you can do is with a commit message
# of:
#
#    Changed blah and foo to do this or that. Fixes #10 and #12, and refs #12.
#
# This will close #10 and #12, and add a note to #12.

We can also add some other commands.

[bas]

will close it. we have no inline_properties and ticket_update_by_subject