Forum OpenACS Development: BehaveLikeOutlookP

I am facing the situation that a client of ours needs "Real" email sending, which means that you are sending *one* email to multiple "to", multiple "cc" and multiple "bcc" recipients. The goal is that the recipients are able to see who else recieved this e-mail.

Sadly acs-mail-lite sends out single emails for each of these recipients.

I played around a little bit with complex_send and managed to add a "cc" flag to it which correctly sends the emails in CC. I think I could go the same way with BCC.

Sadly though this does not work with multiple "to" recipients as both acs_mail_lite::sendmail and ::smtp are spliting the recipients array up and send out individual emails for each of them. Imagine the fun the "cc" guys had when I used 3 "to" recipients (they got three individual e-mails).

Which brings me to my questions:

a) Is sending separate E-Mails the behaviour people would expect when they call acs-mail-lite::send with multiple email recipients. After all you would like to send one e-mail to multiple recipients otherwise you would just call acs-mail-lite::send separately for every user.
b) as a change to "a)" requires a TIP I am inclined to add a parameter "BehaveIndividualMailsP", default to "1" which will send only one email with multiple "to" and "cc" and "bcc" if set to 0. The alternative would be to clone acs-mail-lite::complex_send and create a new procedure for this kind of e-mail sending.

Assuming I have the problem solved and I only send out "one" e-mail, the next challenge lies in the mail-tracking. Obviously you would like the e-mail to show up in each recipients mail-tracking view. So I had been thinking about getting rid of the recipient_id field and add a "recipients" "cc" and "bcc" field which contains the list of e-mail addresses the e-mail was send to. Furthermore I would create a mapping table for "log_id / recipient_id" where the recipient_id belongs to any of the "to" "cc" or "bcc" recipients used in the email.

So far, so good (... I hope, objections and critique more than welcome). But what do we do with e-mail addresses that are not in the system? How are we tracking them? At the moment I am adding a new person (as I can't add just a new party, though maybe I could change party::new to add me a party without an object_type), as I would like to search for the person in the contacts interface (okay, search for the e-mail). But is this a desired behaviour in general or should I turn this on/off using a parameter in mail-tracking? I would add the person into the "mail_tracking_recipients" group so you could quickly filter them out and probably do something useful with them (like enter the real first_names / last_name).

Does the last part make any sense or would you say "don't bother" and add an "email" field to mail-tracking mapping table, so that you could either search by party_id (if known) or email address (if unknown) and add the ability to filter by e-mail address to the mail-tracking include?

I noticed Malte added this code to acs-mail-lite after posting:

# The CC E-Mail is unknown in the system. Create the person.
	    if {[string eq "" $party_id]} {
		if {[regexp {(.+)[\.|_](.+)@(.+)} $email_addr match first_names last_name url]} {
		    set name "$first_names $last_name"
		} else {
		    set name $email_addr
		    set first_names "."
		    set last_name [lindex [split $email_addr "@"] 0]
		}
		if {$contacts_p} {
		    set party_id [contacts::person::new -email $email_addr -first_names $first_names -last_name $last_name]
		    ns_log Notice "Contact generated for $first_names $last_name at $email_addr"
		} else {
		    set party_id [person::new -email $email_addr -first_names $first_names -last_name $last_name]
		    ns_log Notice "Person generated for $first_names $last_name at $email_addr"
		}
	    }

Now we have contacts specific code in an essential package.
Can someone fill me in on the best way to prevent Malte's contacts code from creeping into acs-mail-lite?

Carl

P.S. Malte, why are you adding strangly named people to the system using person::new? Will this effect future registrations if someone has been "added" earlier through inclusion in an email exchange within the contacts package?

A) Giving end users the option of arbitrarily adding others to the database might make sense in applications that you are building for specific business clients, but I am having trouble fitting it into how I want to run my sites/applications so I am very happy to see you remove this code from core because there is a danger others will use it as an example. It is also a relief to hear it was test code, b/c it helps me rationalize why you were falling back on naming people using punctuation if no accurate data is available.

B) Happy to contribute to the discussion but I doubt I will be using contacts for any sites I run. It seems it has become a very "customer relationship management" specific package based on the demos you have given me and the discussion I have had with people about it.

Out of curiosity: As the group_ids are party_ids as well, should complex_send have a -to_group_ids switches in the first place, or should we put the logic to detect if a party_id is a group or not into complex_send.

This would be more logical with regards to the datamodel (after all groups are parties), though it might be a little bit confusing. What do you guys think?