Forum OpenACS Development: Re: Mail Tracking

Collapse
7: Re: Mail Tracking (response to 1)
Posted by Nima Mazloumi on

Mailing List

Sender and Recepient can be anyone. Even non-registered users. But if a mailing list contains users who are not registered at the system a new account is created automatically. So storing the recepient_id is alright. From what I see this is not necessarily true for the sender. So storing the sender_id might break. Should we store the senders email address then as well?

Mailing list has some wrappers for acs-mail-lite but still uses in to finally send emails, so we should be alright with that package.

ML has also some log functionalities: ml_email_log-table stores the senders user_id, the mail_job_id and when the job was sent as send_date while the table ml_mail_jobs stores the complete job content including attributes like mails_sent, mails_bounced. To reconstruct the list of users who actually received the email the table ml_mailing_list_user_map exists. But no versioning is supported. Changing the list will return bad results from a history perspective.

We need to extract the mail specific api and tracking from mailing list into more general packages.

ACS Mail Lite - revisited

The acs_mail_lite_queue table is not very well designed. The attribute to_addr stores a tcl list of the format

email email_address name namefromdb ser_id user_id_if_present_or_empty_string
. This means in the worst case that we don't know who the receiver is.

My suggestion to solve the logging using a trigger makes this a bit tricky since I have to use regular expressions to extract the user_id from to_addr. Here a solution:

v_recepient_id := substring (to_addr from \'user_id ([0-9]+)\');
Now the question is what we do if null is returned. I would suggest we simply raise a notice and fall through without logging that email. Any comments?

Service Contract/ Call Back versus Trigger

Due to the above problems another solution would be to define a service contract or call back instead that is called from each package that wants to log messages sent out. This solution would allow a more application driven compared to the above database driven solution but would also mean that each packages mentioned in my former post need to be touched.

Any comments?