Modify

Opened 13 years ago

Closed 12 years ago

#114 closed enhancement (wontfix)

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

Reported by: eero.afheurlin@… Owned by: bas
Priority: minor Milestone:
Component: email2trac Version: trunk
Keywords: Cc:

Description

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.

Attachments (0)

Change History (7)

comment:1 Changed 13 years ago by 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)

comment:2 Changed 13 years ago by bas

  • Status changed from new to assigned

Did you find a solution

comment:3 Changed 13 years ago by 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.

comment:4 Changed 13 years ago by bas

  • Version changed from 0.4 to trunk

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?

comment:5 Changed 13 years ago by bas

yes if the subject line is intact

comment:6 Changed 12 years ago by 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.

comment:7 Changed 12 years ago by bas

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

will close it. we have no inline_properties and ticket_update_by_subject

Add Comment

Modify Ticket

Change Properties
Action
as closed The owner will remain bas.
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.