flexible ticket notification rules

[anonymous]

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.

[rfonseca@…]

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.

[anonymous]

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.

[Matthew Good]

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.

[Matthew Good]

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

[Matthew Good]

#2247 has been marked as a duplicate of this ticket.

[Christian Boos]

Marked #2447 as duplicate of this one, among others.

[Christian Boos]

See also #4056.

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

[ThurnerRupert]

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

[Remy Blank]

Closed #6465 as a duplicate.

[anonymous]

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.

[Ethan Jucovy <ethan.jucovy@…>]

FYI, I recently released a plugin that allows configuration of flexible notification rules:

​WorkflowNotificationPlugin

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.

[anonymous]

ok I will try it, thanks!

[Mojca Miklavec <mojca@…>]

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:

• ​https://trac.macports.org/ticket/48365
• ​https://trac.macports.org/ticket/39383

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)

[anonymous]

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.

[Ryan J Ollos]

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 INotificationSubscribers, like the ones proposed in #11870.

[Ryan J Ollos]

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.

[Mojca Miklavec <mojca@…>]

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

[Ryan J Ollos]

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

[Peter Suter]

See also wiki:CookBook/Notification/Subscriptions