#2073 closed enhancement (wontfix)
flexible ticket notification rules
Reported by: | anonymous | Owned by: | |
---|---|---|---|
Priority: | low | Milestone: | |
Component: | notification | Version: | 0.8.4 |
Severity: | normal | Keywords: | notification email |
Cc: | dpeterson@…, dserodio@…, vyt@…, direvus@…, shishz@…, mjhweb-trac-tickets@…, sdyson@…, volker@…, ethan.jucovy@…, mojca@… | Branch: | |
Release Notes: | |||
API Changes: | |||
Internal Changes: |
Description
We have a need to e-mail a group of people when a ticket is created, but all those people don't need an e-mail when the ticket is modified. For example, consider a project where multiple people monitor tickets for ones that need immediate action but once someone has picked it up, no one else has to hear about it again if they don't want to.
My suggested fix is to add new config options that split the 'smtp_always_cc' functionality into different events such as ticket creation, ticket modified, ticket assigned, ticket closed, etc. so that you'd end up with 'smtp_always_notify_ticket_creation', 'smtp_always_notify_ticket_modification', etc. If you keep the original config option and just add new ones, then its easy to configure addresses that want all events as well as those who only want a subset of events.
Attachments (0)
Change History (36)
comment:2 by , 19 years ago
Summary: | Ability to send e-mail notifications on ticket creation → Ability to send e-mail notifications on ticket creation only |
---|
comment:3 by , 19 years ago
Maybe would be better to establish a relashionship on components and usergroups so this grouo could receive email on ticket creation.
Is that an 'instead-of' type thing or an 'in-addition-to' type thing? While I could live with configuring the same set of users to ticket creation on multiple components (calls for a mailing list), the problem I see is that not everyone submitting tickets knows what is the right component to submit a ticket to. So if you approach a solution as e-mails bound to components, Trac should send an e-mail on any event that introduces the ticket to that component team. That is, tickets who's component value was just changed should send an e-mail to that component team as if the ticket was new to Trac.
comment:4 by , 19 years ago
Milestone: | → 1.0 |
---|---|
Owner: | changed from | to
Priority: | high → low |
Summary: | Ability to send e-mail notifications on ticket creation only → flexible ticket notification rules |
Well, I think that along with some of my planned refactoring of the notification system I can try to provide another extension point for defining notification rules. Based on the ticket and information about the status changes that occurred, implementations could return a list of the people to notify.
Default implementations would be provided for at least the existing smtp_always_cc
, notify_reporter
, and notify_owner
settings, as well as the CC field of the ticket. Additional implementations for custom notification rules could be added via a plugin.
comment:5 by , 19 years ago
Cc: | added |
---|
comment:6 by , 19 years ago
#2200 requested that notifications of "trivial" changes such as modifying the CC field, or keywords would not send notifications, which could be addressed by this ticket.
comment:7 by , 19 years ago
Cc: | added |
---|
comment:9 by , 19 years ago
Cc: | added |
---|
comment:10 by , 19 years ago
Keywords: | notification email added |
---|
comment:11 by , 19 years ago
Cc: | added |
---|
comment:12 by , 19 years ago
Milestone: | 1.0 → 0.12 |
---|
Marked #2447 as duplicate of this one, among others.
comment:13 by , 19 years ago
Cc: | added |
---|
comment:14 by , 19 years ago
Cc: | gunnar@wagenknecht.org,dpeterson@enthought.com, dserodio@gmail.com, vyt@vzljot.ru, direvus@gmail.com, shishz@hotpop.com → gunnar@wagenknecht.org, dpeterson@enthought.com, dserodio@gmail.com, vyt@vzljot.ru, direvus@gmail.com, shishz@hotpop.com |
---|
comment:15 by , 19 years ago
Cc: | added |
---|
comment:16 by , 18 years ago
Cc: | removed |
---|
comment:18 by , 18 years ago
Owner: | changed from | to
---|
comment:19 by , 18 years ago
#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:20 by , 18 years ago
wouldn't groups/roles the less confusing solution? and as long as groups/rules do not have settings for emails one might just create a technical user, like "change control board" with an attached email address (a list or group box).
an example work flow would then be:
- default assign a component to a technical user
- if somebody out of that group takes it with "accept" the owner changes
- if the component is changed the owner of the ticket might be changed too (reassign, either automatic or the one who changes the component does it) and normal notification rules apply.
with a personal settings solution like suggested in #4056 "notify_reporter", and "notify_owner" could go away and the notification configuration would get simpler instead of more complicated.
therefor i'd really appreciate if #4056 would get a higher prio … and maybe this ticket would then be a "won't fix" or a "is not necessary at all"?
comment:21 by , 17 years ago
Cc: | added |
---|
comment:22 by , 16 years ago
Cc: | added |
---|
comment:24 by , 14 years ago
Milestone: | next-major-0.1X → unscheduled |
---|
comment:25 by , 12 years ago
Component: | ticket system → notification |
---|
comment:26 by , 12 years ago
I could not really understand if this has been added or not, looking at the documentation I could not see any way doing this, but I agree with the inital reporter that it is needed.
comment:27 by , 12 years ago
Cc: | added |
---|
FYI, I recently released a plugin that allows configuration of flexible notification rules:
It is tied to Trac's configurable workflow system, and lets you define notifications to be sent out when certain workflow operations occur. Administrators can configure Genshi text templates that are used for each notification's body, subject, and recipients, using the Trac ticket's pre-change and post-change data as the template context.
You can also define conditions for notifications, e.g. "Only send this notification if the ticket's new resolution is 'fixed'."
I've been using it to send out notifications to one set of users when tickets are created; another kind of notification to a different set of users when tickets are reassigned; another notification when tickets are fixed or wontfixed; etc. I've disabled Trac's default notifications altogether by turning off all of Trac's notification settings (SMTP_ALWAYS_CC, ALWAYS_NOTIFY_REPORTER, ALWAYS_NOTIFY_UPDATER, etc) and just use this plugin to configure flexible notifications.
I know there has been discussion about refactoring Trac's notification options, but this plugin has been working well for me so far.
comment:29 by , 9 years ago
Owner: | removed |
---|
follow-up: 33 comment:30 by , 8 years ago
Cc: | added |
---|
We have another use case. (Maybe that requires a different approach than the one suggested here, I'm not sure.) We occasionally need tickets that affect a huge number of developers. Each one of them has to do a trivial change only and we want to track the progress. Here are some examples:
The problem is that a ticket asking 100 people to do one change each would generate hundred emails to hundred developers when individual changes get implemented (if people modify the description field, that is).
An alternative is to modify a reply, but the reply can only be edited by a single person and that person has a lot of extra work to collect emails and edit the field.
We would love to have the ability to edit the tickets without generating emails. But we would still want occasional reminders or whatever to be sent to everyone in CC. That could be accomplished in different ways. Some solutions that come to my mind:
- having a separate field similar to descriptions that would not generate email traffic
- having a checkbox saying "don't send an email when I add these changes"
- being able to a reply with a checkbox "anyone can edit text of this reply" (people could then edit reply without generating more email traffic)
- open 100 new tickets and only display a ticket query in the master ticket (I don't like that idea too much though)
- open two tickets, one to notify developers, the other one without any subscribers to actually track the progress (ideally I would like to have the ability to include the whole description field from another ticket)
comment:31 by , 8 years ago
Consider creating a custom INotificationSubscriber single file plugin. It seems everyone has their own custom special case requirements. With a custom plugin anyone can easily add special checks for "small changes", CC-only changes, new un-owned tickets or whatever and filter out such notifications.
follow-up: 34 comment:32 by , 8 years ago
Milestone: | unscheduled |
---|---|
Resolution: | → wontfix |
Status: | new → closed |
See also QuietPlugin.
As noted in comment:31, the request in comment:description can be implemented in Trac 1.2 by implementing an INotificationSubscriber
. The subscriber rule might by Notify: Any ticket is created.
Therefore I'm closing this ticket as wontfix, because I think the request is too specific for us to implement in Trac. However, we will probably add more INotificationSubscriber
s, like the ones proposed in #11870.
comment:33 by , 8 years ago
Replying to Mojca Miklavec <mojca@…>:
We have another use case.
I think it could be good to take the discussion of your use case over to the trac-users MailingList. I have ideas on how to solve your issue, and would be happy to commit some time to implementing a plugin (if needed), for such a big and important open source project that uses Trac ;)
If you start a thread on trac-users with your ideas on how to solve it we can start discussing potential solutions.
comment:34 by , 8 years ago
Ryan, thanks a lot for the offer (and sorry for spamming this ticket). I didn't know about QuietPlugin and maybe it already serves our needs. The documentation is scarse, so we need to take a closer look at the sources of the plugin. I subscribed to the mailing list, but let us first evaluate what that plugin offers to get a better idea of what else we might need. We are in the process of major structural changes right now, so this might not be the only "missing feature" :)
comment:35 by , 8 years ago
QuietPlugin might need to be updated to work with Trac 1.2. Trac 1.2 should be out within a month and you'll probably want to move to that version because of the enhanced notification system. Basically, Trac adopted major pieces of AnnouncerPlugin, which QuietPlugin was created to work with.
I'm interested to hear more about your configuration when you get your needs sorted out.
Maybe would be better to establish a relationship on components and usergroups so this group could receive email on ticket creation. This is something like a Change Control Board referred by CMM.