reduce useless emails by not sending to the person causing the notification

[anonymous]

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)"

[anonymous]

Modified Notify.py

[anonymous]

Modified web_ui.py

[anonymous]

With this fix, emails aren't sent to the person causing the changes.

[pacopablo]

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

[Emmanuel Blot]

I agree, this should be an option.

[Emmanuel Blot]

Should be fixed in [3275]

[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',

[Emmanuel Blot]

You're right, I'll fix it this evening.

[Emmanuel Blot]

Fixed in [3291]

[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?

[Christian Boos]

Related to the user preferences idea.

[sid]

Deleting milestone since 0.10 has been closed.

[Matthew Good]

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.

[anonymous]

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.

[Emmanuel Blot]

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?

[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.

[Emmanuel Blot]

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?

[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.

[Christian Boos]

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.

[Emmanuel Blot]

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

[Christian Boos]

Ok, moving to 0.12.

[Christian Boos]

Actually, this is already discussed in #2247, if I'm not mistaken.