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 relashionship on components and usergroups so this grouo 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.

[mgood]

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.

[mgood]

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

[mgood]

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

[cboos]

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

[cboos]

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

[rblank]

Closed #6465 as a duplicate.