Ticket #3093 (closed defect: duplicate)
Opened 6 years ago
Last modified 5 years ago
reduce useless emails by not sending to the person causing the notification
| Reported by: | anonymous | Owned by: | eblot |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | ticket system | Version: | 0.10.3 |
| Severity: | normal | Keywords: | notification |
| Cc: | pacopablo@… | ||
| Release Notes: | |||
| API Changes: | |||
Description
When using email notification of ticket changes, Trac emails the person causing the changes if they are the owner or requestor. This is useless since the person causing the notification should be aware that they are actually making changes to the ticket.
The fix is relatively simple:
in Notify.py:
near line 166:
change: "def notify(self, ticket, newticket=True, modtime=0):"
to: "def notify(self, req, ticket, newticket=True, modtime=0):
self.req = req"
near line 145:
change: "self.server.sendmail(self.from_email, [rcpt], msg.as_string())"
to: "if(rcpt != self.email_map[self.req.authname]):
self.server.sendmail(self.from_email, [rcpt], msg.as_string())"
in ticket/web_ui.py:
near line 144:
change: "tn.notify(ticket, newticket=True)"
to: "tn.notify(req, ticket, newticket=True)"
near line 352:
change: "tn.notify(ticket, newticket=False, modtime=now)"
to: "tn.notify(req, ticket, newticket=False, modtime=now)"
Attachments
Change History
Changed 6 years ago by anonymous
comment:1 Changed 6 years ago by anonymous
With this fix, emails aren't sent to the person causing the changes.
comment:2 Changed 6 years ago by pacopablo
- Cc pacopablo@… added
I like the idea. However, I think that this should be optional. I know that I like getting notification of all changes, be they mine or someone else's.
I wonder what it would take to make this configurable via trac.ini
comment:3 Changed 6 years ago by eblot
- Keywords notification email added
I agree, this should be an option.
comment:4 Changed 6 years ago by eblot
- Milestone set to 0.10
- Owner changed from jonas to eblot
- Status changed from new to assigned
comment:5 Changed 6 years ago by eblot
- Resolution set to fixed
- Status changed from assigned to closed
Should be fixed in [3275]
comment:6 Changed 6 years ago by anonymous
- Resolution fixed deleted
- Status changed from closed to reopened
comment:7 Changed 6 years ago by anonymous
I think there's an error in [3725]
at line 39 of notification.py
always_notify_reporter = BoolOption('notification', 'always_notify_updater',
should be
always_notify_updater = BoolOption('notification', 'always_notify_updater',
comment:8 Changed 6 years ago by eblot
You're right, I'll fix it this evening.
comment:9 Changed 6 years ago by eblot
- Resolution set to fixed
- Status changed from reopened to closed
Fixed in [3291]
comment:10 follow-up: ↓ 13 Changed 5 years ago by anonymous
- Resolution fixed deleted
- Status changed from closed to reopened
I'm just arguing with the guy in charge of our trac setup whether this option should be on or off. He wants it on, I want it off. Is there any way we could make the setting on a per user basis?
comment:11 Changed 5 years ago by cboos
Related to the user preferences idea.
comment:12 Changed 5 years ago by sid
- Milestone 0.10 deleted
Deleting milestone since 0.10 has been closed.
comment:13 in reply to: ↑ 10 Changed 5 years ago by mgood
- Milestone set to 0.10
- Resolution set to fixed
- Status changed from reopened to closed
Replying to anonymous:
I'm just arguing with the guy in charge of our trac setup whether this option should be on or off. He wants it on, I want it off. Is there any way we could make the setting on a per user basis?
I'm going to restore the status of this ticket since its original purpose has already been met. I've opened #4166 for adding a Preferences panel to configure notification settings per-user.
comment:14 follow-up: ↓ 15 Changed 5 years ago by anonymous
- Resolution fixed deleted
- Status changed from closed to reopened
- Version changed from 0.9.4 to 0.10.3
It appears that this feature doesn't work (at least in version 0.10.3 with sqlite backend). I set always_notify_owner, always_notify_reporter, always_notify_updater = false, create ticket, add myself (my username) to cc list of ticket, submit changes, then modify ticket and submit changes again. Trac sends me notification about the last changes, despite I am the author of them.
comment:15 in reply to: ↑ 14 ; follow-up: ↓ 16 Changed 5 years ago by eblot
- Keywords email removed
Replying to anonymous:
add myself (my username) to cc list of ticket, submit changes, then modify ticket and submit changes again. Trac sends me notification about the last changes, despite I am the author of them.
I'm not sure to understand: is your email address still in the CC list?
comment:16 in reply to: ↑ 15 ; follow-up: ↓ 17 Changed 5 years ago by anonymous
Replying to eblot:
Replying to anonymous:
add myself (my username) to cc list of ticket, submit changes, then modify ticket and submit changes again. Trac sends me notification about the last changes, despite I am the author of them.
I'm not sure to understand: is your email address still in the CC list?
Yes, it is (but it is not e-mail, it is the name of user used in HTTP authentication; I have configured my e-mail address for this user in trac settings). As far as I can understand, trac shouldn't send notification to me in this case, even if I am still in the CC list.
comment:17 in reply to: ↑ 16 ; follow-up: ↓ 18 Changed 5 years ago by eblot
Replying to anonymous:
As far as I can understand, trac shouldn't send notification to me in this case, even if I am still in the CC list.
Nope, the CC list takes precedence here. I'm not sure about what you want to achieve here: what's the point to add yourself to a CC list if you do not want to get notified?
comment:18 in reply to: ↑ 17 Changed 5 years ago by anonymous
Nope, the CC list takes precedence here. I'm not sure about what you want to achieve here: what's the point to add yourself to a CC list if you do not want to get notified?
I suppose i should not receive any notifications about changes made by me, despite the presence of my address in CC field (or any other parameters that could cause sending me the notification otherwise) - like it is done, for example, in Bugzilla. As noticed in ticket description, receiving notifications about changes made by myself is quite useless.
The same problem is observed if I don't add myself to CC list, but always_notify_owner=true and I am the owner of the ticket. If I set this parameter to false I don't receive any notifications at all, if I set it to true I receive all notifications, even caused by my modifications of ticket.
comment:19 Changed 5 years ago by cboos
- Milestone changed from 0.10 to 0.10.4
comment:20 follow-up: ↓ 21 Changed 5 years ago by cboos
comment:21 in reply to: ↑ 20 Changed 5 years ago by eblot
Replying to cboos:
I think the reopening is due to #3780 and to the r4299 changeset.
I think that always_notify_updater == false should probably override the other always_notify_... = true options.
I think that this should be postponed to a more serious refactoring of the notification options (a per-user rather than per-site settings). There will always be some combination of settings/actions with the current solution that will either fail to trigger a notification, or notify some users more that they expect.
I would therefore suggest to postpone this ticket till 0.12, as it seems the notification refactoring won't happen for 0.11
comment:23 Changed 5 years ago by cboos
- Resolution set to duplicate
- Status changed from reopened to closed
Actually, this is already discussed in #2247, if I'm not mistaken.
comment:24 Changed 5 years ago by cboos
- Milestone 0.12 deleted



Modified Notify.py