#8673 closed defect (worksforme)
Reporter gets two emails each time his ticket is modified
Reported by: | Owned by: | Emmanuel Blot | |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | notification | Version: | 0.11.1 |
Severity: | normal | Keywords: | always_notify_reporter, smtp_always_cc |
Cc: | andreavb1985+trac@… | Branch: | |
Release Notes: | |||
API Changes: | |||
Internal Changes: |
Description
I'm using Debian 5.0 stable and Trac 0.11.1-2.1, hosting about 80 projects. Each project has its own mailing list. Sometimes, an user needs to open a ticket into a project that he doesn't belong to (so, he doesn't belong to the mailing list either), and he needs to get updated about his ticket being commented and/or closed.
So, I have the following configuration at my projects:
always_notify_reporter = true smtp_always_cc = projectmailinglist@myownserver.com
This works pretty fine, except for some duplicated e-mails… Whenever an user opens a ticket into a project that he *belongs* to, he gets two e-mails for every modification (creating/updating/closing the ticket).
I've used this configuration before (Trac 0.10), and it was ok (people received e-mail if they belonged to project and if they opened the ticket, but only one email per person).
Attachments (0)
Change History (5)
comment:1 by , 15 years ago
Resolution: | → worksforme |
---|---|
Status: | new → closed |
follow-up: 3 comment:2 by , 15 years ago
Yeah, that's the problem: if the reporter doesn't belong to the project (ie, he is not subscribed to the ML), he won't get the notification, although he needs it. However, if the reporter belongs to the project, he gets two e-mails, which is a little bit annoying.
The weird thing is that it really used to work in Trac 0.10, but doesn't work in Trac 0.11. I have to choose between "getting 2 e-mails" or "getting no e-mail at all" (in which situation, of course). Is there no way to fix it?
always_notify_owner = false always_notify_reporter = true always_notify_updater = false
comment:3 by , 15 years ago
Replying to andreavb1985+trac@…:
Is there no way to fix it?
I don't see how:
- The ML engine does not know Trac sends an email directly to the owner
- Trac does not know the ML engine, and cannot guess who's subscribed to a peculiar ML
There would be two ways to manage such a configuration:
- Write a ML engine as a Trac plugin ;-)
- Do not use a ML engine to deliver notifications, but an alias list on the SMTP server (so that it can remove duplicates)
I don't know if there are some "smart" ML engines out there that would be able to detect duplicates on their own.
Is the use_public_cc
setting enabled? Maybe the ML engine can analyze the To:
and Cc:
headers of the emails sent from Trac, and automagically remove the recipients from its own delivery list.
follow-up: 5 comment:4 by , 15 years ago
Hi, Manu, sorry for the late.
Thank you very much for your efforts in helping me.
I don't use a ML engine, but some alias.
I've tried both use_public_cc enabled and disabled, it didn't change things.
It seems I'll have to live with that. Or that I'll write the plugin (unfortunately, it's unlikely to happen, but it would be interesting) :)
Regards
comment:5 by , 15 years ago
Replying to anonymous:
I don't use a ML engine, but some alias.
I've tried both use_public_cc enabled and disabled, it didn't change things.
Maybe the SMTP server does not remove duplicate as it used to / should do it.
If you have access to the SMTP log files, it would be interested to check out how the server handles the incoming notifications.
You'll have to tweak the SMTP settings to disable always_notify_owner.
The SMTP server receives two emails, one from Trac, the other one from the ML engine. The only way to shut this off is to tell Trac not to emit a notification for the owner, as the ML engine takes care of it.
The drawback is that if the owner has not subscribed to the ML, he won't get notifications at all.