Edgewall Software
Modify

Opened 16 years ago

Closed 6 years ago

#2247 closed enhancement (duplicate)

[PATCH] Option to prevent notification to self

Reported by: direvus@… Owned by: Ryan J Ollos
Priority: normal Milestone:
Component: notification Version: 0.11.4
Severity: normal Keywords: notification, patch, preferences
Cc: nielsen@…, mzizka@…, oleg.pudeyev@…, john.ferg@…, macke@…, rantingman@…, spam@…, felix.schwarz@…, gr.tracedgewal@…, ethan.jucovy@…, cfboekelo@… Branch:
Release Notes:
API Changes:
Internal Changes:

Description

If I'm logged in and making changes to tickets, I don't see any value in getting an email about it.

For me, the usefulness of the notification system is in alerting the interested parties to the fact that a change has occurred.

If you're the one who made the change, you already know that it has occurred. Why would you want to get an email about it?

I'd like to propose that we add an option either to User Settings or to trac.ini called notify_self or similar, and make it possible to disable this unintuitive behaviour.

Attachments (6)

trac-never-notify-self-2247.patch (2.1 KB ) - added by nielsen@… 16 years ago.
Patch to suppress notifying self of changes one is making via web interface
trac-no-notify-updater-2247.patch (857 bytes ) - added by nielsen@… 15 years ago.
Makes 'always_notify_updater = false' work as expected
005_no-self-notify.patch (1.7 KB ) - added by Sebastian Krysmanski <sebastian@…> 12 years ago.
Patch against Trac 0.11.4
notify_own_changes-0.11.7.patch (1.4 KB ) - added by stef@… 11 years ago.
Sebastian's patch for 0.11.7
notify_own_changes.013dev-r10668.patch (1.7 KB ) - added by gt4329b 11 years ago.
version of the patch for 0.13dev-r10668
notify_own_changes.1.0.patch (1.5 KB ) - added by dave 9 years ago.
version for 1.0

Download all attachments as: .zip

Change History (79)

comment:1 by dserodio@…, 16 years ago

Cc: dserodio@… added

comment:2 by Matthew Good, 16 years ago

Resolution: duplicate
Status: newclosed

This will be addressed by #2073.

by nielsen@…, 16 years ago

Patch to suppress notifying self of changes one is making via web interface

comment:3 by nielsen@…, 16 years ago

Cc: nielsen@… added
Component: generalticket system
Resolution: duplicate
Status: closedreopened
Version: 0.9b10.9.2

I don't think this is a duplicate of #2073. This is about getting notifications of changes one is making via the web interface, regardless of whether one is the ticket owner, reporter or whatever.

The attached patch adds an option for this issue: never_notify_self

Again, this is so that when I make a change in the web interface, it suppresses notifications to me (even if i'm in the CC, reporter, owner or other fields).

This option greatly increases the utility of notifications by suppressing spam to yourself, and only being notified of changes that other people make.

comment:4 by sid, 15 years ago

Summary: Option to prevent notification to self[PATCH] Option to prevent notification to self

comment:5 by Christian Boos, 15 years ago

Milestone: 1.0

This looks like a User Preference to me. I don't think the Trac administrator can here make a choice that will sound appropriate for all users. Think about TracHacks, where hundreds of people collaborate on loosely related projects.

So this is really something that should be set on an individual basis, and I think that we should come up with a scheme similar to the TracIni settings, but for user settings (some existing settings would better be served as user settings: timeline's daysback, wiki space in page names, wiki hide missing pages, etc.)

in reply to:  5 comment:6 by Emmanuel Blot, 15 years ago

Replying to cboos:

This looks like a User Preference to me. I don't think the Trac administrator can here make a choice that will sound appropriate for all users.

BTW,

[notification]
always_notify_updater

already addresses the original request for this ticket, doesn't it?

comment:7 by Christian Boos, 15 years ago

Milestone: 1.0
Resolution: duplicate
Status: reopenedclosed

Manu, you're right: this ticket is actually a duplicate of #3093, which you implemented for 0.10.

The name of the option is a bit misleading though: at first sight, I had the impression that always_notify_updater would be about always sending the notification to the updater, regardless of the fact if he was on CC or not. But always_notify_updater = false has actually the same meaning as the never_notify_self = true suggested in this ticket.

My point about User Preferences still stands, I think.

in reply to:  7 comment:8 by Emmanuel Blot, 15 years ago

Replying to cboos:

My point about User Preferences still stands, I think.

Yes, it truly does - I was commenting on the original request.

comment:9 by maz, 15 years ago

Resolution: duplicate
Status: closedreopened

I think this should be reopened. As far as I can tell, since r4299, the always_notify_updater option does what its name implies, i.e. notify the updater of a change if set to true. When set to false, the owner and reporter will still be notified (#3780).

So always_notify_updater no longer fills the need of a notify_self option as above. To be clearer, what would be nice is a never_notify_self option, that we could set to true to prevent the person making the change from receiving an update. I may be mistaken, but currently (0.10.3) there is no way to achieve this. Hence in my opinion this ticket is still valid. If I am wrong, please close it again and accept my apologies.

These notification options are becoming confusing. Having the word "always" on every option name does not help any. Something like this would have been simpler IMO (just pulling this out of a hat, didn't put too much thought into it):

notify_reporter = always|except_self|never
notify_owner = always|except_self|never

Of course, using this strategy, a person in the smtp_always_(b)cc field would still receive a notification when updating a ticket, so who knows. And in any case, better still would be to implement this as user preferences as per #4056.

in reply to:  9 comment:10 by Emmanuel Blot, 15 years ago

Keywords: notification needinfo added
Version: 0.9.20.10.3

Replying to maz:

notify_reporter = always|except_self|never
notify_owner = always|except_self|never

This seems an interesting alternative. always_notify_* troubles come (up to a certain level) from a wish to keep compatibility in option naming with the previous Trac releases. Maybe it's time to rename some of these options.

I don't think the user preferences can be implemented for 0.11. What do the other developers think about implementing this system-wide options for 0.11: do it make sense ?

in reply to:  9 comment:11 by direvus@…, 15 years ago

Replying to maz:

These notification options are becoming confusing. Having the word "always" on every option name does not help any.

Agreed. The word "always" is very strange in this context. If always_notify_updater is true, the semantics are clear: we want Trac to always notify the updater.

But if always_notify_updater is false, what does that mean? We want Trac to not always notify the updater. "Not always" is ambiguous. It could mean "never", it could mean "sometimes", it could mean "almost all the time". So in the end it's not obvious to a Trac administrator how these options behave when set to false.

comment:12 by ThurnerRupert, 15 years ago

maybe better addressed by #4056?

comment:13 by maz <mzizka@…>, 15 years ago

Cc: mzizka@… added

by nielsen@…, 15 years ago

Makes 'always_notify_updater = false' work as expected

comment:14 by nielsen@…, 15 years ago

Not a real fix, but thought I'd post the patch I'm using in my Trac deployments. Just in case anyone wants a quick fix for this.

comment:15 by Christian Boos, 15 years ago

Component: ticket systemnotification
Milestone: 0.12

#3093 was marked as duplicate, which discussed essentially the same thing.

comment:16 by anonymous, 14 years ago

Cc: oleg.pudeyev@… added

comment:17 by john.ferg@…, 14 years ago

Cc: john.ferg@… added

comment:18 by john.ferg@…, 14 years ago

It seems quite a few people would like this enhancement, including myself. I suggest an increase in both priority and severity.

comment:19 by adam@…, 14 years ago

Note that someone has written a Trac plugin to prevent notifications to updaters. You can find it here:

th:NeverNotifyUpdaterPlugin

Last edited 7 years ago by Ryan J Ollos (previous) (diff)

comment:20 by Christian Boos, 13 years ago

Keywords: needinfo removed
Severity: trivialnormal

comment:21 by Marcus Lindblom <macke@…>, 13 years ago

Cc: macke@… added

comment:22 by Chris Carr <rantingman@…>, 13 years ago

Cc: rantingman@… added

So if always_notify_owner is TRUE and always_notify_updater is FALSE, I should not receive notification emails when updating my own tickets? That would be sensible - but it's not what happens in 0.11.1 (Debian Lenny). So it seems that the original request is still outstanding (unless this has been fixed in a later version).

in reply to:  22 comment:23 by anonymous, 13 years ago

Replying to Chris Carr <rantingman@…>:

So if always_notify_owner is TRUE and always_notify_updater is FALSE, I should not receive notification emails when updating my own tickets? That would be sensible - but it's not what happens in 0.11.1 (Debian Lenny).

Same here on 0.11.4. At work we're using 0.10.something and this feature is working correctly. I assume it broke somewhere on the way?

comment:24 by spam@…, 13 years ago

Cc: spam@… added

added myself to cc.

by Sebastian Krysmanski <sebastian@…>, 12 years ago

Attachment: 005_no-self-notify.patch added

Patch against Trac 0.11.4

comment:25 by Sebastian Krysmanski <sebastian@…>, 12 years ago

Milestone: 0.130.12
Version: 0.10.30.11.4

I've attached a patch that works for me. It adds an option called notify_own_changes to the [notification] section. If this option is false (which is the default) you will only be notified about changes made by others. If it's true you will also be notified about changes you made yourself. I hope this helps.

Also I'm changing the version here to 0.11.4 as the problem still exists in this version.

comment:26 by Sebastian Krysmanski <sebastian@…>, 12 years ago

Cc: sebastian@… added

Adding myself to cc.

comment:27 by Remy Blank, 12 years ago

Milestone: 0.120.13

Thanks for working on this! However, as mentioned in the description and comment:5, this should actually be a per-user setting instead of system-wide.

(Please don't change the milestone for tickets. This will be done by the developer who integrates the changes, according to the version where he wants it to be done.)

in reply to:  27 ; comment:28 by Sebastian Krysmanski <sebastian@…>, 12 years ago

Replying to rblank:

Thanks for working on this! However, as mentioned in the description and comment:5, this should actually be a per-user setting instead of system-wide.

Right, but until then I think in most cases you don't want to be notified about your own doings. I think notification means: "Tell me when something happens I don't know of." But the user already knows about his changes.

(Please don't change the milestone for tickets. This will be done by the developer who integrates the changes, according to the version where he wants it to be done.)

Sorry for that. I thought it was an error as I couldn't find any comment that set this to 0.13.

in reply to:  28 ; comment:29 by Remy Blank, 12 years ago

Replying to Sebastian Krysmanski <sebastian@…>:

Sorry for that. I thought it was an error as I couldn't find any comment that set this to 0.13.

Ah, yes, that would be #5658: when closing a milestone and re-targeting tickets to another milestone, no comment is added to the individual tickets.

I agree that it would make sense not to send notifications to the user doing them by default. OTOH we try not to add too many config options, especially when they would be obsoleted shortly (for a certain value of "shortly") by a per-user setting.

in reply to:  29 ; comment:30 by Chris Carr <rantingman@…>, 12 years ago

Replying to rblank:

I agree that it would make sense not to send notifications to the user doing them by default. OTOH we try not to add too many config options, especially when they would be obsoleted shortly (for a certain value of "shortly") by a per-user setting.

Given that the comment about a per-user setting was made three years ago, and that there have been no fewer than sixteen milestone releases since then, perhaps we could have Sebastian's notify_own_changes option included in the next release? I'm sure nobody would complain if it was then "shortly" obsoleted by the introduction of user preferences.

in reply to:  30 comment:31 by Daniel Serodio <dserodio@…>, 12 years ago

Replying to Chris Carr <rantingman@…>:

Replying to rblank:

I agree that it would make sense not to send notifications to the user doing them by default. OTOH we try not to add too many config options, especially when they would be obsoleted shortly (for a certain value of "shortly") by a per-user setting.

Given that the comment about a per-user setting was made three years ago, and that there have been no fewer than sixteen milestone releases since then, perhaps we could have Sebastian's notify_own_changes option included in the next release? I'm sure nobody would complain if it was then "shortly" obsoleted by the introduction of user preferences.

As a "mere" user, I fully agree

comment:32 by Felix Schwarz <felix.schwarz@…>, 12 years ago

Cc: felix.schwarz@… added

comment:33 by anonymous, 12 years ago

Cc: gr.tracedgewal@… added

by stef@…, 11 years ago

Sebastian's patch for 0.11.7

comment:34 by rantingman@…, 11 years ago

Does anybody know why this wasn't included in 0.12? It's such a tiny change and would make such a big difference to so many people. Please could it be included soon? Pretty please?

comment:35 by Thijs Triemstra, 11 years ago

Keywords: patch added

by gt4329b, 11 years ago

version of the patch for 0.13dev-r10668

comment:36 by anonymous, 11 years ago

I am also confused. I options are called always_notify_owner then I thought that keeping it set to false means that owner of the ticket is notified sometimes (eg. when someone else modifies the ticket) but not always. But it seems that he is never notified. I had to change it to true - but it is very frustrating because he gets notifications even about his own changes. So never_notify_self would be a great relief here!

comment:37 by anonymous, 10 years ago

Please could the supplied patch be added to 0.13?

in reply to:  37 comment:38 by clopez@…, 10 years ago

Replying to anonymous:

Please could the supplied patch be added to 0.13?

+1

comment:39 by dserodio@…, 10 years ago

Cc: dserodio@… removed

comment:40 by Ethan Jucovy <ethan.jucovy@…>, 10 years ago

Cc: ethan.jucovy@… added

comment:41 by rantingman@…, 9 years ago

So this didn't make it into 1.0 - shame! There appears to be a voting system for tickets now - everybody vote for it!!

comment:42 by Christian Boos, 9 years ago

Keywords: userpreferences added
Milestone: next-major-releasesnext-dev-1.1.x
Priority: lownormal

The help text for the setting in the patch is not crystal clear…

What about something like:

exclude_own_changes = BoolOption('notification', 'exclude_own_changes', 
                                 'false',
    """Don't send a notification for the user who triggered it. 
    This exclusion takes effect after any mechanism that could
    add the user as recipient (`always_notify_*`, `smtp_always_*`
    settings).""")

comment:43 by Peter Suter, 9 years ago

#7999 was closed as a duplicate.

comment:44 by expectedcoincidence, 9 years ago

Cc: cfboekelo@… added

by dave, 9 years ago

version for 1.0

comment:45 by lkraav <leho@…>, 8 years ago

I'm looking for a way to stop all e-mails as user preference, so the never_* thing from years is appealing. This is a use case when one has a solid feed subscription already in place and e-mails just duplicate everything.

Does it fit under this ticket?

comment:46 by lkraav <leho@…>, 8 years ago

But! Important part is that I would still like to sit in visible CC lists, because it communicates to others that I'm actively interested in this and that.

in reply to:  45 comment:47 by Ryan J Ollos, 8 years ago

Replying to lkraav <leho@…>:

I'm looking for a way to stop all e-mails as user preference,

You might take a look at the subscription preference panel for AnnouncerPlugin trunk. I think it has an option that covers the case you are interested in, and integration of AnnouncerPlugin to Trac seems like the most promising route for major enhancements to Trac's notification system.

in reply to:  45 ; comment:48 by jared.bownds@…, 8 years ago

Replying to lkraav <leho@…>:

I'm looking for a way to stop all e-mails as user preference, so the never_* thing from years is appealing. This is a use case when one has a solid feed subscription already in place and e-mails just duplicate everything.

Does it fit under this ticket?

Have you made any progress concerning this feature?

A simple check box residing next to the "Submit changes" button would suffice. When checked it would disable email notifications from being sent to reporter, cc, or owner.

comment:49 by Ryan J Ollos, 7 years ago

Keywords: preferences added; userpreferences removed

in reply to:  48 comment:50 by Ryan J Ollos, 7 years ago

Replying to jared.bownds@…:

A simple check box residing next to the "Submit changes" button would suffice. When checked it would disable email notifications from being sent to reporter, cc, or owner.

That sounds more like #8607.

comment:51 by Ryan J Ollos, 7 years ago

Milestone: next-dev-1.1.x1.0.3
Owner: changed from Jonas Borgström to Ryan J Ollos
Status: reopenedassigned

Summarizing the ticket:

Therefore I'm going to propose a fix for 1.0.3, adding an option named never_notify_self. The option will probably be removed when the notification rule system of AnnouncerPlugin is integrated. I've added a deprecation notice at NeverNotifyUpdaterPlugin@22.

Proposed changes in log:rjollos.git:t2247-never-notify-self.

comment:52 by Peter Suter, 7 years ago

Personally I would prefer to move forward with TracDev/Proposals/AdvancedNotification. It was stalled for a long time waiting for the 1.1.2 release, but I would be happy to discuss any issues that would prevent refreshing and merging the changes proposed there so far for 1.1.3.

Adding new options in the meantime seems a bit counterproductive to me.

in reply to:  52 ; comment:53 by Christian Boos, 7 years ago

Replying to psuter:

Personally I would prefer to move forward with TracDev/Proposals/AdvancedNotification. It was stalled for a long time waiting for the 1.1.2 release, but I would be happy to discuss any issues that would prevent refreshing and merging the changes proposed there so far for 1.1.3.

I wasn't aware of your psuter.hg@advanced-notification-preferences branch, it looks really nice and I indeed think it would be worth integrating. You could perhaps rebase it on a recent trunk to ease the testing?

As usual, I'm looking for a middle ground… ;-) Ryan, your fix looks like a nice solution for 1.0-stable, do you see an easy transition path from your 'never-notify-self' to Peter's new framework (some INotificationSubscriber returning 'never' for the user triggering the event?).

in reply to:  53 comment:54 by Ryan J Ollos, 7 years ago

Replying to cboos:

Ryan, your fix looks like a nice solution for 1.0-stable, do you see an easy transition path from your 'never-notify-self' to Peter's new framework (some INotificationSubscriber returning 'never' for the user triggering the event?).

Thanks, I'll look into that. I'd like to provide something for 1.0-stable since we'll be supporting that for some time and there's a need for a fix.

in reply to:  53 ; comment:55 by Peter Suter, 7 years ago

Replying to cboos:

You could perhaps rebase it on a recent trunk to ease the testing?

Sure, I also plan to fold in Jun's improvements for easier reviewing. Oh, I didn't notice the changes from #2259 before, so it's not entirely trivial to rebase.

Maybe I should commit log:psuter@advanced-notification-preliminary-refactorings so at least these don't have to be rebased again later.

I'm not opposed to provide something for 1.0-stable, e.g. after merging this branch (which I hoped to do in the next few days).

in reply to:  55 ; comment:56 by Ryan J Ollos, 7 years ago

Replying to psuter:

Maybe I should commit log:psuter@advanced-notification-preliminary-refactorings so at least these don't have to be rebased again later.

I'll hold off committing anything for this ticket until all your changes are committed. The changes in this ticket are pretty small, so it'll be no problem to wait and rebase my changes before committing towards the end of milestone:1.0.3, adding an upgrade step on the trunk if necessary to migrate the never_notify_self option to the new notification preference module (haven't yet looked at what might required).

Last edited 7 years ago by Ryan J Ollos (previous) (diff)

comment:57 by Peter Suter, 7 years ago

Thanks.

I updated the branch psuter.hg@advanced-notification-preferences.2.

Most relevant to this ticket is TicketUpdaterSubscriber, a INotificationSubscriber that allows subscribers to get notifications if they update a ticket, or conversely 'never' to get such notifications. A new never_notify_self option might indeed fit in here, e.g. as a 'never' "default subscription". The always_notify_updater option already enables the 'always' default subscription.

(That option so far also notified past updaters. I think that was confusing and unpopular, and should be dropped here. We can maybe provide a cookbook recipe example to implement this behavior separately if anyone actually wants it.)

comment:58 by bobbysmith007@…, 7 years ago

I am the author of the th:NeverNotifyUpdaterPlugin. I am happy for this solution to finally be a part of trac (as it seems a more logical behaviour, to my users, than the current default behaviour).

I glanced through the diff of log:rjollos.git:t2247-never-notify-self and it all seemed reasonable and in line with what my plugin was doing.

Thanks for updating the plugin wiki page, and progressing this work toward inclusion.

in reply to:  57 ; comment:59 by Dirk Stöcker, 7 years ago

Replying to psuter:

(That option so far also notified past updaters. I think that was confusing and unpopular, and should be dropped here. We can maybe provide a cookbook recipe example to implement this behavior separately if anyone actually wants it.)

What do mean? We e.g. use the feature that "commenting once" means "be notified". While this may be uncommon for experience bug tracker users it's very helpful for non-experienced users. So don't drop that possibility! Let the users (or the admin) choose whether they want that.

in reply to:  59 comment:60 by Ryan J Ollos, 7 years ago

Replying to dstoecker:

Replying to psuter:

(That option so far also notified past updaters. I think that was confusing and unpopular, and should be dropped here. We can maybe provide a cookbook recipe example to implement this behavior separately if anyone actually wants it.)

What do mean? We e.g. use the feature that "commenting once" means "be notified". While this may be uncommon for experience bug tracker users it's very helpful for non-experienced users. So don't drop that possibility! Let the users (or the admin) choose whether they want that.

Right, the two behaviors just need to be controlled through separate preferences.

I found the notify past updaters behavior to be confusing until I started thinking differently about the option. always_notify_updater results in all updaters of the ticket being notified, including the user currently updating the ticket. However, the latter could be interpreted as just a consequence of the former, with the former being the primary intent of the option. It might be better named always_notify_updaters to indicate everyone that has ever updated the ticket.

never_notify_updater gives updater a definite different meaning, which is why I proposed naming the option never_notify_self.

However, replying to comment:3:ticket:11835:

  • I also thought about trac-author-self, but if this is appeals to the dev, it could maybe a bit obscure for the admin; anyway, it should be clear that by "user" we mean the currently logged in user (e.g. #150)

I see what you are saying though about self being confusing to the administrator, who need to be thinking of self from the standpoint of the user editing the ticket (this will be different when we have per-user notification options and self can be interpreted as the user configuring their notifications). Any thoughts on whether updater or self should be used in the never_notify option? It probably doesn't matter as much with the option likely only living as long as 1.0.x series.

comment:61 by Dirk Stöcker, 7 years ago

Actually I think "self" is understandable also for the admin.

comment:62 by Peter Suter, 7 years ago

Oh OK then. Thanks for explaining.

past_updaters and current_updater would maybe be most clear. But I'm not sure it's worth changing now. self also seems quite understandable to me.

in reply to:  59 comment:63 by Peter Suter, 7 years ago

Replying to dstoecker:

What do mean? We e.g. use the feature that "commenting once" means "be notified". While this may be uncommon for experience bug tracker users it's very helpful for non-experienced users. So don't drop that possibility! Let the users (or the admin) choose whether they want that.

See comment:35:ticket:4056.

in reply to:  56 comment:64 by Peter Suter, 7 years ago

Replying to rjollos:

I'll hold off committing anything for this ticket until all your changes are committed. The changes in this ticket are pretty small, so it'll be no problem to wait and rebase my changes before committing towards the end of milestone:1.0.3, adding an upgrade step on the trunk if necessary to migrate the never_notify_self option to the new notification preference module (haven't yet looked at what might required).

I have now committed all related changes.

TicketUpdaterSubscriber and TicketPreviousUpdatersSubscriber implement always_notify_updater for the current updater and past updaters respectively, and could be extended to implement never_notify_self as well.

comment:65 by anonymous, 7 years ago

This *really* needs to go into 1.0.3 nobody is so senile that they forget what they just posted…

in reply to:  56 comment:66 by Peter Suter, 7 years ago

Replying to rjollos:

adding an upgrade step on the trunk if necessary to migrate the never_notify_self option to the new notification preference module

In #11875 I propose a new [notification-subscriber] section and an upgrade step to migrate always_notify_* to that. never_notify_self could be handled there as well.

comment:67 by Ryan J Ollos, 7 years ago

Milestone: 1.0.31.0.4

comment:68 by Sebastian Krysmanski <sebastian@…>, 7 years ago

Cc: sebastian@… removed

comment:69 by Ryan J Ollos, 7 years ago

Milestone: 1.0.41.0.5

comment:70 by Ryan J Ollos, 7 years ago

Milestone: 1.0.51.0.6

Narrowing focus for 1.0.5.

comment:71 by Ryan J Ollos, 7 years ago

Milestone: 1.0.61.0.7

comment:72 by Ryan J Ollos, 6 years ago

Milestone: 1.0.71.2

comment:73 by Ryan J Ollos, 6 years ago

Milestone: 1.2
Resolution: duplicate
Status: assignedclosed

Since we have the preference in Trac 1.2 Never Notify: I Update a Ticket, I think this issue is resolved. Closing as a duplicate of #11875.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain Ryan J Ollos.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from Ryan J Ollos to the specified user.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.