[merge]Support e-mail notifications for local users

[naked@…]

Some way to send e-mail notifications for unqualified local users would be useful. What I mean by this is that default logins on a web server are just plain usernames, such as "naked" - and emails could be either sent unqualified to "naked", or a domain could be configured for all the addresses that would be appended to the end, or there could be a more complex lookup operation for obtaining the e-mail addresses.

For me, a sufficient solution would be a configuration option "smtp_allow_local_names", that would also send email notifications to names that are returned by pwd.getpwnam(). This is, however, quite a specific solution.

[daniel]

We could possibly use the new session mgmt capability to get email addresses of authenticated users.

[daniel]

Email addresses are now (starting in [617]) kept in a session variable (if entered in settings).

'local' users a'la UNIX is a bad idea since we can't rely on users putting anything reasonable in the reporter/email/cc fields, which could potentially result in alot of mail bounces.

[holger krekel <hpk@…>]

Sorry, you say "'local' users a'la UNIX is a bad idea since we can't rely on users putting anything reasonable in the reporter/email/cc".

Isn't the risk of mail bounces higher if people need to put in fully qualified email addresses?

And if a user sets an email address in his settings can i then reference it by simply specifying that users username?

Generally i am very interested in enhancing trac's email features so i am trying to understand where it is today.

[tbrkic]

Patch added.

The patch does:

If you in trac.ini have set

[notification] 
user_domain = domain.com

Then when trac send out emails it will:

• check if the address contains @ => sends email to that address

• If the address doesnt contain any @. Then check if it is a user on the local system. If so send out email to user@user_domain.

So if you dont set user_domain everything works as before.

The advantage you get is if you setup trac in a company where 'getpwnam' works and the trac username is the same as the unix username. In this case the user will get notification when tickets change. And in cc and assign fields it is enought to write the username which will probably lead less typing errors.

Cheers

Toni

[tbrkic]

patch

[jonas]

This might be a good idea but we should use email addresses stored in the session if they exist before starting to construct them from user names.

Moving this to 0.9...

[tom@…]

Here is a further patch to send emails to a local ticket *owner* as well as the reporter.

[tom@…]

Notify a local ticket owner as well as the reporter

[cmlenz]

#1286 has been marked as duplicate of this ticket.

[David M. Lee <dmlee@…>]

Yet another notify patch. This one digs email addresses out of the session table, instead of assuming that users live in the same domain, relying on other system config, or other such unreliable information. This is (hopefully) more like what Daniel intended.

If a username has multiple email addresses from multiple sessions, only the first one is used.

Really, a name and email should be associated with the username, and not the session. The only time it makes sense for a session is for the user 'anonymous'. It would be nice if there were a 'Users' table for holding this sort of information.

The patch is made against 0.8-stable.

[David M. Lee <dmlee@…>]

Notify patch that maps usernames to email using the session information

[cmlenz]

David, this functionality has already been added to trunk in [1343]. See also #866.

This ticket remains open as a request to support notification to local users, in case they don't have an email address set in their session.

[cmlenz]

As we now support mapping plain user names in the CC, reporter and owner fields to the email address set in the users settings, I don't think that trying to send mail to local users is really worth it.

[anonymous]

I believe for the user_domain patch to work for cc users you need to redefine parse_cc to call get_email_addresses instead.