Edgewall Software
Modify

Opened 17 years ago

Last modified 9 years ago

#6078 new enhancement

[PATCH] Enabling multiple email notification for a single user.

Reported by: christophe.sauthier@… Owned by:
Priority: low Milestone: unscheduled
Component: notification Version:
Severity: minor Keywords: patch consider
Cc: sdyson@…, jsiirola@…, jean-gui@…, leho@…, tonibony@… Branch:
Release Notes:
API Changes:
Internal Changes:

Description

Here is a simple patch to enable the possibility to provide multiple email addresses for a user. Once this patch is applyed, the user has just to write the multiple coma-separated addresses. He will receive notification on all the addresses. I've used that to provide multiple adresses (and so many people) behind components.

This patch works with the latest svn, as well as with the 0.10.X branches. I also have the equivalent for the 0.9 branch if you are interested.

Attachments (2)

multiple_email_notifications.diff (974 bytes ) - added by christophe.sauthier@… 17 years ago.
recursive-multiple-email-addresses.diff (2.1 KB ) - added by jsiirola@… 16 years ago.
Patch against 0.11-stable to recursively resolve multiple email addresses

Download all attachments as: .zip

Change History (18)

by christophe.sauthier@…, 17 years ago

comment:1 by anonymous, 17 years ago

Cc: sdyson@… added

by jsiirola@…, 16 years ago

Patch against 0.11-stable to recursively resolve multiple email addresses

comment:2 by jsiirola@…, 16 years ago

Cc: jsiirola@… added
Keywords: patch added

I just added a patch against branches/0.11-stable that recursively resolves notification email addresses.

As with the original reporter, this patch allows me to set up virtual Trac users that represent groups of Trac developers. I assign these groups to be the default owners of new tickets created against specific components. By allowing the virtual user's email field to contain multiple Trac users or email addresses, I can directly leverage Trac's notification system without the need for external mailing list software. In addition, this solution automatically follows each Trac user's e-mail preferences (including the option to send their mail to multiple addresses or other users).

comment:3 by Remy Blank, 16 years ago

Resolution: duplicate
Status: newclosed

This is a duplicate of #2662.

comment:4 by jsiirola@…, 16 years ago

Resolution: duplicate
Status: closedreopened

Actually, this ticket is not a duplicate of #2662. #2662 requests that a single ticket be able to be assigned to multiple Trac users. This ticket is requesting that a single trac user be able to register multiple e-mail addresses.

I am afraid that in my previous comment (2) I may have confused matters by mentioning a use for this feature that is similar in spirit to #2662.

in reply to:  4 ; comment:5 by Remy Blank, 16 years ago

Replying to jsiirola@…:

I am afraid that in my previous comment (2) I may have confused matters by mentioning a use for this feature that is similar in spirit to #2662.

Ok. Could you provide a use case for this feature (besides having notifications sent to e.g. a private and a business e-mail address)?

comment:6 by Remy Blank, 16 years ago

Keywords: consider added
Milestone: 2.0

in reply to:  5 ; comment:7 by jsiirola@…, 16 years ago

Replying to rblank:

Ok. Could you provide a use case for this feature (besides having notifications sent to e.g. a private and a business e-mail address)?

Yes. I am actively using this patch for several projects as I described in 2 to define development teams. The team user lists all the individuals on the team in its email field. Components have different teams defined as their default owner. This not only notifies the entire team when new tickets are submitted / modified, but it also makes it very clear which tickets have actually been claimed by a developer (and avoids the case where key developers end up "owning" lots of tickets that they have no intention of actually working on.

While I could approximate this behavior with trunk Trac combined with external mailing lists, this patch makes it entirely self-contained within Trac — including following each Trac user's e-mail preference setting (instead of forcing me to maintain a slew of e-mail lists and attempting to keep the lists in sync with each Trac user's current e-mail setting).

This is also (IMHO) more elegant than having tickets explicitly assigned to each member of the development team (as would be possible with #2662). It presents a graphically simpler interface (no long list of developers), and does not require submitters / triagers to remember all of the members of every development team. Plus, if a new developer is added to the team, you do not have to go back and add them to all of the pre-existing tickets.

in reply to:  7 comment:8 by turbidostato <turbidostato@…>, 16 years ago

Priority: normallow
Severity: normalminor

Replying to jsiirola@…:

Replying to rblank:

Ok. Could you provide a use case for this feature (besides having notifications sent to e.g. a private and a business e-mail address)?

Yes. I am actively using this patch for several projects as I described in 2 to define development teams. The team user lists all the individuals on the team in its email field.

I see your point, but I think you are using a hammer for a screwdriver.

Instead of being Trac, which is not a mailserver, the one resolving guidevelopers@… into albert@…, beth@… and carl@… ask the mailserver to do it; after all, that's its job. That's the use for either mail expansion aliases or mail lists. You could even have just a simple guidevelopers@… account somewhere and have Albert, Beth and Carl accesing it through a shared IMAP folder.

Regarding your team assigments, I would point that one thing is to assign a task to a group (which I think is quite reasonable) and a very different one who is effectively working on it. So while you could assign some task to the guidevelopers team, once accepted and work taking place it will be Albert, Beth or Carl the one effectively working on it, so the ticket should be assigned to the guidevelopers team no more but owned by one of its members.

Finally, if you really don't want to know about Albert, Beth and Carl, then it's just a matter for all of them loging in under the same guidevelopers account (probably not only against trac but against the underlying SCM too) -not that I think this would be a good idea.

comment:9 by jean-gui@…, 16 years ago

Cc: jean-gui@… added

(I also answered to #2662)

I've created a plugin which adds a field "Default CC" per component. This field allows to specify a list of mail addresses or users that will be automatically added to the CC list when new tickets (of the corresponding component) are created. That's not exactly what the ticket is about, but the discussion is related, so I thought some of you might be interested.

comment:10 by Remy Blank, 16 years ago

#8154 was closed as a duplicate.

in reply to:  5 comment:11 by ben@…, 16 years ago

I would like to see this in Trac as well. The use case that I have is that I use email2trac, which receives email sent to a dedicated address and turns that email into Trac tickets. In doing so, it needs to map email senders to Trac users. Since there is no way to specify more than one email address for a user, email2trac is unable to correctly handle users who send their bug reports from more than one address.

comment:12 by arontseedco@…, 15 years ago

I would also like to see this in Trac as well. In re: the repsone do it on the mail server: You are assuming that the trac admin has control over the mail server in the organziation, which is not always the case. We have a trac system here installed on a server we control, but it is a pain in the neck to get IT to add the mail aliases and can take days or weeks. Also some requests they may not allow at all (e.g. an alias which is multiple email addresses for same person). Allowing multiple emails in the preferences gives us control of the situation and allows us to get the behaviors we need without having to rely on an external force (i.e. the recalcitrant IT department).

comment:13 by Christian Boos, 15 years ago

Milestone: 2.0unscheduled

Milestone 2.0 deleted

comment:14 by lkraav <leho@…>, 12 years ago

Cc: leho@… added

comment:15 by Ryan J Ollos, 10 years ago

Owner: Emmanuel Blot removed
Status: reopenednew

comment:16 by Stoyan Ivanov <tonibony@…>, 9 years ago

Cc: tonibony@… added

Modify Ticket

Change Properties
Set your email in Preferences
Action
as new The ticket will remain with no owner.
The ticket will be disowned.
as The resolution will be set. Next status will be 'closed'.
The owner will be changed from (none) to anonymous. Next status will be 'assigned'.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.