Child pages
  • [emails] Add Email Details feature to Email Logs [5.3.0-B1]
Skip to end of metadata
Go to start of metadata

Imported From: http://groups.google.com/group/in-portal-dev/browse_thread/thread/c937c2dbdfe12c48#

Hi guys,

For some time we had a task sitting in In-Portal Tracker  INP-54 - Getting issue details... STATUS .

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.

Related Tasks

INP-1003 - Getting issue details... STATUS

INP-1204 - Getting issue details... STATUS

17 Comments

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

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

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

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

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

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

  7. Hi,

    We actually decided to create a separate task for his:

    *1228: Email Log Rotation and New Fields*
    *
    *

    INP-1003 - Getting issue details... STATUS

    *
    *
    *
    *
    DA
  8. 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

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

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

  11. There are 2 tasks mentioned in this discussion:

       -

    INP-54 - Getting issue details... STATUS

    - not completed and that's
       why already in Icebox
       -

    INP-1003 - Getting issue details... STATUS

    - completed in 5.2.0-B3
       (actually represents comments inside
       

    INP-54 - Getting issue details... STATUS

    task)

    This way we only need to decide whatever we still need functionality
    explained in

    INP-54 - Getting issue details... STATUS

    task.

    On Thu, Oct 18, 2012 at 7:48 AM, Dmitry A. <dandre...@gmail.com> wrote:
    > 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

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

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

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

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

  16. I've created following task, that contains Ideas from my previous post:

    INP-1204 - Getting issue details... STATUS