Edgewall Software

Ticket #2247 (reopened enhancement)

Opened 3 years ago

Last modified 4 weeks ago

[PATCH] Option to prevent notification to self

Reported by: direvus@… Owned by: jonas
Priority: low Milestone: 0.13
Component: notification Version: 0.10.3
Severity: normal Keywords: notification
Cc: dserodio@…, nielsen@…, mzizka@…, oleg.pudeyev@…, john.ferg@…

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

trac-never-notify-self-2247.patch (2.1 KB) - added by nielsen@… 3 years ago.
Patch to suppress notifying self of changes one is making via web interface
trac-no-notify-updater-2247.patch (0.8 KB) - added by nielsen@… 23 months ago.
Makes 'always_notify_updater = false' work as expected

Change History

  Changed 3 years ago by dserodio@…

  • cc dserodio@… added

  Changed 3 years ago by mgood

  • status changed from new to closed
  • resolution set to duplicate

This will be addressed by #2073.

Changed 3 years ago by nielsen@…

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

  Changed 3 years ago by nielsen@…

  • cc nielsen@… added
  • resolution duplicate deleted
  • status changed from closed to reopened
  • component changed from general to ticket system
  • version changed from 0.9b1 to 0.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.

  Changed 2 years ago by sid

  • summary changed from Option to prevent notification to self to [PATCH] Option to prevent notification to self

follow-up: ↓ 6   Changed 2 years ago by cboos

  • milestone set to 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   Changed 2 years ago by eblot

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?

follow-up: ↓ 8   Changed 2 years ago by cboos

  • status changed from reopened to closed
  • resolution set to duplicate
  • milestone 1.0 deleted

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   Changed 2 years ago by eblot

Replying to cboos:

My point about User Preferences still stands, I think.

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

follow-ups: ↓ 10 ↓ 11   Changed 2 years ago by maz

  • status changed from closed to reopened
  • resolution duplicate deleted

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   Changed 2 years ago by eblot

  • keywords notification needinfo added
  • version changed from 0.9.2 to 0.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   Changed 2 years ago by direvus@…

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.

  Changed 2 years ago by ThurnerRupert

maybe better addressed by #4056?

  Changed 2 years ago by maz <mzizka@…>

  • cc mzizka@… added

Changed 23 months ago by nielsen@…

Makes 'always_notify_updater = false' work as expected

  Changed 23 months ago by nielsen@…

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.

  Changed 21 months ago by cboos

  • component changed from ticket system to notification
  • milestone set to 0.12

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

  Changed 17 months ago by anonymous

  • cc oleg.pudeyev@… added

  Changed 10 months ago by john.ferg@…

  • cc john.ferg@… added

  Changed 10 months ago by john.ferg@…

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

  Changed 8 months ago by adam@…

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

http://trac-hacks.org/wiki/NeverNotifyUpdaterPlugin

  Changed 4 weeks ago by cboos

  • keywords needinfo removed
  • severity changed from trivial to normal

Add/Change #2247 ([PATCH] Option to prevent notification to self)

Author



Change Properties
<Author field>
Action
as reopened
as The resolution will be set. Next status will be 'closed'
to The owner will change from jonas. Next status will be 'new'
 
Note: See TracTickets for help on using tickets.