#3361 closed defect (fixed)
changes in notification cause breakage in email2trac
Reported by: | Owned by: | Emmanuel Blot | |
---|---|---|---|
Priority: | normal | Milestone: | 0.10 |
Component: | ticket system | Version: | devel |
Severity: | major | Keywords: | notification email2trac |
Cc: | Branch: | ||
Release Notes: | |||
API Changes: | |||
Internal Changes: |
Description
The changes made in source:/trunk/trac/ticket/notification.py@3468 break the notification functionality used in the email2trac plugin functionality. The version prior to this check-in allowed you to submit a ticket via email and email2trac would be able to parse the submitted email's From: address and then a proper notification would be sent out to that email address to let them know their ticket was received.
After upgrading to source:/trunk/trac/ticket/notification.py@3468 if I send email in (via email2trac) response notifications are no longer sent to the person submitting the ticket via email. Instead it seems to be picking up the real name that is included in a typical from:
From: "Micah Anderson" <micah@riseup.net>
and then failing to send notification to "Micah Anderson" (due to it being an incorrect email address), rather than trying to send the notification to <micah@…>. The log says:
2006-07-05 18:48:32,360 Trac[notification] INFO: Email address w/o domain: Micah Anderson
This resulted in the ticket filed with email2trac here, but after experimenting with the code from various versions, I see that it was a change in notification.py that caused this, rather than the email2trac plugin.
Thanks!
Attachments (0)
Change History (7)
comment:1 by , 18 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
follow-up: 3 comment:2 by , 18 years ago
Milestone: | 0.10 |
---|
Actually, I was wrong, there's already a piece of test code that checks that "Joe User" <joe.user@example.org>
syntax is properly handled by the notification code.
Something weird though is that the "From" address is supposed to be set to the Trac engine, not to the submitter's address of a ticket. It seems from the example you sent that the emailtotrac script changes this default behaviour.
How do you exactly call the notification handler ?
(resetting the target milestone as it does seem to be a show stopper for the Trac core)
follow-up: 4 comment:3 by , 18 years ago
Replying to eblot:
How do you exactly call the notification handler ?
Yes, I think that this might be the problem…
The notify method signature has changed, it now takes a req
argument:
def notify(self, ticket, req, newticket=True, modtime=0):
comment:4 by , 18 years ago
Replying to cboos:
The notify method signature has changed, it now takes a
req
argument:def notify(self, ticket, req, newticket=True, modtime=0):
Which, BTW, I'd really like to change back. The email notifications should not require a HTTP request object. They should use the base_url
of the Trac environment (env.abs_href
or env.base_url
) even if there's a different Host
header in the request. In the future (0.11-ish) we should make email notifications require that option to be set in TracIni.
comment:5 by , 18 years ago
+1 to remove it, for the same reason: avoid useless dependencies (strong coupling) between modules.
comment:7 by , 18 years ago
Milestone: | → 0.10 |
---|---|
Resolution: | → fixed |
Status: | assigned → closed |
Closing this ticket as cboos has reverted the API change and the unit test passes w/o any trouble with the reported email address.
The email2trac plugin script has not been tested against r3550 though. Please re-open this ticket if it still fails.
This syntax is not tested (as not really used from the Trac interface), and there's probably a regression at this level. I'll have a look at it.