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

[christophe.sauthier@…]

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.

[jsiirola@…]

Patch against 0.11-stable to recursively resolve multiple email addresses

[jsiirola@…]

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

[rblank]

This is a duplicate of #2662.

[jsiirola@…]

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.

[rblank]

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

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

[turbidostato <turbidostato@…>]

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.

[jean-gui@…]

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

[rblank]

#8154 was closed as a duplicate.

[ben@…]

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.

[arontseedco@…]

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

[cboos]

Milestone 2.0 deleted