Edgewall Software
Modify

Opened 19 years ago

Closed 8 years ago

Last modified 7 years ago

#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:1 by rfonseca@…, 19 years ago

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.

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

comment:2 by rfonseca@…, 19 years ago

Summary: Ability to send e-mail notifications on ticket creationAbility to send e-mail notifications on ticket creation only

comment:3 by anonymous, 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 Matthew Good, 19 years ago

Milestone: 1.0
Owner: changed from Jonas Borgström to Matthew Good
Priority: highlow
Summary: Ability to send e-mail notifications on ticket creation onlyflexible 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 dserodio@…, 18 years ago

Cc: dserodio@… added

comment:6 by Matthew Good, 18 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 anonymous, 18 years ago

Cc: vyt@… added

comment:8 by Matthew Good, 18 years ago

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

comment:9 by anonymous, 18 years ago

Cc: direvus@… added

comment:10 by anonymous, 18 years ago

Keywords: notification email added

comment:11 by anonymous, 18 years ago

Cc: shishz@… added

comment:12 by Christian Boos, 18 years ago

Milestone: 1.00.12

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

comment:13 by anonymous, 18 years ago

Cc: gunnar@… added

comment:14 by anonymous, 18 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 anonymous, 18 years ago

Cc: mjhweb-trac-tickets@… added

comment:16 by anonymous, 18 years ago

Cc: gunnar@… removed

comment:17 by Christian Boos, 17 years ago

See also #4056.

comment:18 by Alec Thomas, 17 years ago

Owner: changed from Matthew Good to Alec Thomas

comment:19 by sid, 17 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 ThurnerRupert, 17 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 anonymous, 16 years ago

Cc: sdyson@… added

comment:22 by Volker <volker@…>, 16 years ago

Cc: volker@… added

comment:23 by Remy Blank, 15 years ago

Closed #6465 as a duplicate.

comment:24 by Remy Blank, 14 years ago

Milestone: next-major-0.1Xunscheduled

comment:25 by Peter Suter, 11 years ago

Component: ticket systemnotification

comment:26 by anonymous, 11 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 Ethan Jucovy <ethan.jucovy@…>, 11 years ago

Cc: ethan.jucovy@… added

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.

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

comment:28 by anonymous, 11 years ago

ok I will try it, thanks!

comment:29 by Ryan J Ollos, 9 years ago

Owner: Alec Thomas removed

comment:30 by Mojca Miklavec <mojca@…>, 8 years ago

Cc: mojca@… 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 anonymous, 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.

comment:32 by Ryan J Ollos, 8 years ago

Milestone: unscheduled
Resolution: wontfix
Status: newclosed

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.

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

in reply to:  30 comment:33 by Ryan J Ollos, 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.

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

in reply to:  32 comment:34 by Mojca Miklavec <mojca@…>, 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 Ryan J Ollos, 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.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The ticket will remain with no owner.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from (none) 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.