Ticket #4056 (new enhancement)
Opened 5 years ago
Last modified 22 months ago
Notification Preferences
| Reported by: | jeff.wise@… | Owned by: | athomas |
|---|---|---|---|
| Priority: | normal | Milestone: | next-major-0.1X |
| Component: | notification | Version: | 0.10 |
| Severity: | normal | Keywords: | notification email |
| Cc: | |||
| Release Notes: | |||
| API Changes: | |||
Description
My team has been using Trac for 3 months now. Overall its been a great success. However, some team members complain that they receive lots of e-mail that doesn't matter to them. This eventually leads to their ignoring Trac e-mails. An example would be when they are placed on the CC list of a ticket and later someone changes one of the ticket properties. They aren't interested in ticket property changes.
I've searched, but I haven't found a mechanism to customize the notification preferences on a per user basis. There is global configuration in TracIni, but no means for a user to indicate the kind of notifications they are interested in receiving.
I would like for a user to indicate which notifications they would like to receive:
- All (The current behaviour)
- None
- Ticket Creation
- Addition of Comments/Replies?
- All Ticket properties
- Owner changes
- Milestone changes
- etc.
Please consider adding this feature to Trac. Thanks.
Attachments
Change History
comment:1 Changed 5 years ago by sid
comment:2 Changed 5 years ago by cboos
- Milestone set to 1.0
See also my note about user preferences settings.
Also, the level of details proposed here looks a bit to high for me, especially if in the future we have also notifications for wiki, milestone, changesets, etc.
So I'd propose a 3-levels setting, matching what we have in the timeline:
- All changes
- Only Status changes
- None
comment:3 Changed 5 years ago by Noah Kantrowitz (coderanger) <coderanger@…>
If coupled with the TracObjects idea, maybe you could keep a list of (resource, field/facet) pairs to base notifications off.
comment:4 Changed 5 years ago by sid
If you are cc'ed on a ticket, you will probably want to know more than just status changes. You probably want to be involved in the discussion as well, and notified of new comments. But possibly care less about ticket property changes.
comment:5 Changed 5 years ago by athomas
- Owner changed from jonas to athomas
comment:6 Changed 5 years ago by sid
#3269 was marked as a duplicate. It contained a patch for the 0.9 branch that hardcoded cc rules to only cc on comment or description changes.
comment:7 Changed 5 years ago by mgood
comment:8 Changed 5 years ago by eblot
- Keywords notification email added
comment:9 Changed 5 years ago by Andy Schlaikjer <hazen@…>
- Cc hazen@… added
comment:10 Changed 5 years ago by sid
#1640 was marked as duplicate of this ticket.
comment:11 Changed 5 years ago by jeff.wise@…
I'd really like to see ticket notification preferences look something like the following. Bullets are like checkboxes.
Notify me when:
- I am the ticket reporter.
- I am the ticket owner.
- I am a ticket updater.
- I am on the ticket CC list.
Notify me of:
- New comments.
- Status changes.
- Resolution changes.
- Property changes.
- List all, including custom, properties here.
comment:12 follow-ups: ↓ 13 ↓ 18 Changed 5 years ago by eblot
I think we gonna face a potential issue here: if notification content are based on user preferences, this means that we'll need to emit one email per recipient - rather than one email for all recipients, as per today.
As notification are synchronous (i.e. the web request completes when all notifications have been sent to the SMTP server), how Trac will behave with numerous recipients ?
Does this mean we need an asynchronous service to actually send the notifications? This is something that should be thought about before starting any user-based content settings.
comment:13 in reply to: ↑ 12 Changed 5 years ago by jeff.wise@…
Replying to eblot:
I think we gonna face a potential issue here: if notification content are based on user preferences, this means that we'll need to emit one email per recipient - rather than one email for all recipients, as per today.
I don't understand the limitation here. Possible recipients are the reporter, owner, updater, and CC list. Use their preferences and the ticket activity to filter the list down to those who care. Then send a single e-mail to the filtered list. Unless the CC list or the set of updaters is incredibly long, it shouldn't take a significant amount of time to filter the recipient list.
comment:14 Changed 5 years ago by hazen@…
- Cc hazen@… removed
comment:15 Changed 5 years ago by ThurnerRupert
this feature would be also very useful for mixed user populations, like "web users" (maybe prefer notification via mail) and eclipse mylar users (get notified by mylar).
comment:16 Changed 5 years ago by ThurnerRupert
maybe prevent a notification to self like addressed in #2247 is also something to consider?
comment:17 Changed 5 years ago by cboos
- Component changed from ticket system to notification
- Milestone changed from 1.0 to 0.12
See also #2625 (preferred format)
comment:18 in reply to: ↑ 12 Changed 4 years ago by Pedro Algarvio, aka, s0undt3ch <ufs@…>
Replying to eblot:
I think we gonna face a potential issue here: if notification content are based on user preferences, this means that we'll need to emit one email per recipient - rather than one email for all recipients, as per today.
As notification are synchronous (i.e. the web request completes when all notifications have been sent to the SMTP server), how Trac will behave with numerous recipients ?
Does this mean we need an asynchronous service to actually send the notifications? This is something that should be thought about before starting any user-based content settings.
Something like the AnnouncerPlugin should be though of.
comment:19 Changed 2 years ago by Carsten Fuchs <CarstenFuchs@…>
I too have problems with users that get too many or too little email notifications.
A suggestion: Why discriminate between reporter, owner and updater at all? Instead, add a checkbox
- Notify me when the ticket is changed (subscribe ticket)
to the "New Ticket" and "Modify Ticket" forms (keep the decision if this checkbox is checked by default as a per user setting), and a "Subscribe ticket (notify me when the ticket is changed)" link to the ticket view pages?
This would be a simple system that meets all requirements, analogous to how e.g. the phpBB forums notify users about replies.
While this replaces the current always_notify_[owner|reporter|updater] settings in trac.ini, the smtp_always_[cc|bcc] settings should be kept.
The only open question is how a user can automatically subscribe to new tickets (e.g. another per user checkbox setting: "Notify me when a new ticket is created").
comment:20 Changed 22 months ago by rcorsaro
I've been working on this: http://trac.edgewall.org/wiki/TracDev/Proposals/Announcer#ProposedAnnouncerPreferences
I could use some feedback.



Similar to, but not quite the same as #2073.