Add Email Details feature to Email Logs

[Dmitry A.]

Hi guys,

For some time we had a task sitting in In-Portal Tracker called #66 Add Email Details feature to Email Logs.

While it describes that we should store some of the information I believe we can definitely store the actual email copy at least for 2 reasons - history, web copy purposes.

Here is are some idea that came to my mind:

1. Store complete Email message that has been sent out to the User. It can play the role of Web Copy when needed.

We should have new fields added which will store:

- Email Subject

- Email Body

- AdditionalRecepients (all recipients like CC, BCC users, groups and so on - it's okay to store)

- EmailKey (random 15 ro 20 alpa-numeric) to be able to reference to this log from the Front end - if needed (will use in URL)

We would need to have some sort of Tag which can be used within the Template and which during the mailing will be build correct URL with proper Key so users can click and view they web version if needed.

2. Create new System Configuration which would allow to specify number days to keep Email logs and delete all older ones (default 30 days). It's kind of rotation. Alternatively we can simple EMPTY the EmailBody field for all Logs older than specified date and this will save lots of space. In other words, who needs a copy of 1+ months old email?

3. Create ScheduledJob which would do cleaning once a day.

Please let me know what you think and if you supporting it.

DA

[Alexander Obuhovich]

All e-mails that are sent from website usually are designated to a specific registered user only.

That's why adding "view web version" link in e-mail doesn't do any good if we plan, that user e-mail is broken and he won't receive anything that we sent him.

Having "sent e-mails" section under "My Account" on Front-End for user to see all e-mails website sent to him isn't good too, since send e-mails for them to appear in user's e-mail client, not on website.

Also most of e-mails website sends are notifications and I see no point of having notification displayed on website too.

--
Best Regards,

http://www.in-portal.com
http://www.alex-time.com

[Phil]

while "view web version" isn't maybe the most useful, having an in-account list of sent emails could be good, because we could also add this to a new tab in admin user's detail: "Communication Log", where we could see all emails that have been sent, automatically and manually to this user.

Yes, I'm suggesting -again- to think about CRM features, wether in a separate module or built-in...

-- 

Phil

Envoyé avec Sparrow

[Alexander Obuhovich]

We can't keep sent e-mails forever, since e-mails tend to be large and communication log with missing e-mails (deleted, because were sent too long ago) isn't good to anyone.

Related to CRM isn't existing "e-mail communication" feature in "Form Submissions" enough for a starters? It keeps all e-mail based communication in admin too. Only limitation is that user first must submit "Contact Us" form on website.

[Phil]

We can't keep sent e-mails forever, since e-mails tend to be large and communication log with missing e-mails (deleted, because were sent too long ago) isn't good to anyone.

emails are mainly text. We can store thousand email in few kb, as far as I know. This special feature could use a text file, easily archivable and deletable (like log files are) 

 

Related to CRM isn't existing "e-mail communication" feature in "Form Submissions" enough for a starters? It keeps all e-mail based communication in admin too. Only limitation is that user first must submit "Contact Us" form on website.

No, because CRM stands for "Customer Relationship Management": you deal with customers, that's why you see your log under user's detail panel, rather than  contact form, where anybody (including non-customer) could write.

And seeking in all received forms for a particular user who became a customer isn't that good at all (and maybe impossible...)

ok, this is not the right thread here, sorry ^^ 

[Alexander Obuhovich]

We actually have "In-Support" module, that wasn't released yet and is used right now for that purpose on http://www.in-portal.com. User has "My Tickets" (or similar) section under "My Account" and he can post N number of tickets (according to it's subscription plan). All user-admin dialog is recorded within that ticket. Tickets have assigned person, that would handle a ticket once it's submitted and question type, asked in ticket. Of course tickets have status, that allows to track their progress.

Maybe it's not what you understand under CRM term.

[Phil]

this is also another interesting feature: a request tracker system. Not exactly a CRM, which tends to focus on commercial exchanges, rather than support.

And it'd be cool to know more about this module :)

-- 

Phil

Envoyé avec Sparrow

[Dmitry A.]

Hi,

We actually decided to create a separate task for his:

1228: Email Log Rotation and New Fields

http://tracker.in-portal.org/view.php?id=1228 

DA

[Phil]

very interesting specs in this task. As email could be very important, and even a critical data in commercial relations, I'd suggest a system to archive, and/or download old logs. The very same way as Apache deal with logs in fact: latest one until X size in text format, older ones in gzip.

Envoyé avec Sparrow

[Dmitry A.]

Thanks for your feedback Phil. Sure, let's come back to auto-gzipping during rotation down the road once we see proposed feature working

DA

[Dmitry A.]

Hi guys,

I was checking on Mantis to see if this task is already Finished/Completed, but there it's not.

I believe we already have completed the task, haven't we? If not let's decide where it goes 5.2.1 or 5.3.0

DA

[Alexander Obuhovich]

There are 2 tasks mentioned in this discussion:

• http://tracker.in-portal.org/view.php?id=66 - not completed and that's why already in Icebox
• http://tracker.in-portal.org/view.php?id=1228 - completed in 5.2.0-B3 (actually represents comments inside http://tracker.in-portal.org/view.php?id=66 task)

This way we only need to decide whatever we still need functionality explained in http://tracker.in-portal.org/view.php?id=66 task.

[Dmitry A.]

Agreed, we need to review and discuss whether task 66 is needed.

Here is what we have in to (key points):

==========
Add ability, to view details of sent emails from email log grid. It's not content of email itself, it's a data, that was associated with email event that was sent.

For example for LINK.ADD or LINK.MODIFY events we could make email log subject a link to editing form of that link. Same for users and other related stuff. This way based on email log (in case of admin haven't received actual email) he/she can view details for each email and why it was sent at all.

==========

Alex, the main question do we have this now and if we don't what do we have in terms of email data related to this that is being saved?

DA

[Alexander Obuhovich]

Right now we only save mailing_id and only, when it caused e-mail to be sent.

Long time has gone, since we created that task originally and I no longer remember what's for we needed all that.

Maybe we can pass 'PrefixSpecial' parameter when we're sending e-mail and then we'll use it to retrieve item's id. Then we can store both inside LogData and then later using code to one similar to AdminEditButton tag build a link to edit that item. However if item was deleted since e-mail was sent, then this editing link would open broken popup. We also can't check if each used item is still "alive", since this would require extra db query for each item.

[Dmitry A.]

I think we can pass on this now since so far current Email Log has been performing pretty well so let's come back to this if there is a real life need for it.

Agreed?

DA

[Alexander Obuhovich]

Agreed.

[Alexander Obuhovich]

Few more ideas after using updated version of "E-mail Logs" section.

I'm proposing to add following fields to each logged e-mail record:

• ToUserId - ID of user, who was intended recipient of e-mail (ID is specified directory to kApplication::EmailEventAdmin/kApplication::EmailEventUser methods)
• ItemPrefix - unit used inside e-mail (e.g. order, user, affiliate)
• ItemId - ID of item used in e-mail

Proposed fields would easily allow to do following (when needed):

• find all e-mail that were sent to a given user (as proposed by Phil several posts ago)
• find all e-mail sent about given item (e.g. all e-mails about given order)