Child pages
  • [emails] Email Event Subscriptions - Part 2
Skip to end of metadata
Go to start of metadata

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

Hi everyone,

Not too long ago we have started the discussion for adding new functionality called "Email Event Subcriptions". We have discussed quite a few options there and come up some basic plan which I'd like to finalize in this discussion and finally create a new Feature Request for this.

Goal

  1. We need flexible way of subscribing users (and/or Emails) to different types of actions. For example I wish to subscribe to receive an email when:
    1. New TOPIC is added to the Forum Category (now TOPIC.ADD event triggered) so it's CATEGORY level subscription.
    2. New POST is added to the TOPIC (now POST.ADD event triggered) so it's TOPIC level subscription.
    3. New CATEGORY is added
    4. Category is modified
    5. ANY type of resource that we have Event changed
  2. It can be managed in Admin (grid) or Front (separate forms/events needs to be programmed)
  3. Emails should be send out to all Users (BCC) once that particular Event / Action is triggered.

NOTE: Recently we have refactored and improved Email Events interfaces and functionality which allows adding CC, BCC of all kinds, BUT it's missing ability to associate the Events with Items. This is something we are looking to have here.

Additionally we can allow subscribe Users which didn't Register, but just entered their email address. On the Front-end there might be additional logic added to verify your subscription so there is NO spamming to 3rd party emails.

Proposed table structure

Table: EmailEventSubscriptions

  • SubscriptionId (auto-increment)
  • PortalUserId (from PortalUser table, default NULL)
  • UserEmail (string default NULL, used in case if user subscribed without Registration - quite useful)
  • EventId (from Events table)
  • CategoryId (from Categories table, default NULL)
  • ItemPrefix (default NULL)
  • ItemId (default NULL)
  • Status (int - Active, Disabled, Pending)
  • ModifiedOn (int with DateTime Formatter)

Admin Interfaces

I think we should have a separate section for this OR since all this is related to current Email Events we can create a new tab called Subscriptions. There we can show the grid of subscribers to that Event + ItemId and Prefix with opens to Add / Remove new ones.

One other thing is that we need to create a new Agent that will Clean things up when Items are removed (deleted) so we don't end up with gazillion unknown records.

Original discussion can be found here: Email Event Subcriptions

Related Tasks

INP-982 - Getting issue details... STATUS

INP-1017 - Getting issue details... STATUS

18 Comments

  1. wow, great job Dmitry, I like this new funtionnality !

    2010/10/29 Dmitry A. <dandre...@gmail.com>

  2. I see 2 different usage strategies here:

       1. subscribe to receive email, when some email event is already sent,
       e.g. TOPIC.ADD (subscription to topic adding in category)
       2. subscribe to receive email, when nothing is currently sent

    For 1st case we should auto-guess if any associated subscription email event
    is created, e.g. TOPIC.ADD*.SUBSCRIBTION *(existing email event name plus
    ".SUBSCRIPTION" at the end).

    For 2nd case we must create a method to send subscription email event by
    name.

    In total there will be 3 general methods:

       - get subscribers by given email event name
       - sent email to subscribers by given event name (called by developer)
       - sent email to subscribers when master email event is called (e.g. send
       TOPIC.ADD.SUBSCRIPTION, when TOPIC.ADD is sent), called by system

  3. I have a suggestion to make:

    What if we add a new drop-down field (TriggersEventId) to an Email
    Event which will allow to map which which Event we want to trigger/
    send when when current is executed. This way we don't need to
    guess .SUBSCRIBE part and we can fully customize whos send with what.

    Drop-down will consist of:

    [None]
    - All Event Names, but current one.

    I don't think we should check for recursion here since in mosts cases
    it will be 1 or 2 triggered events at most and is full responsibility
    of developer if something gets out of hand.

    We can put the field on General or Setting field (probably the best).

    Let me know your thoughts.

    DA

  4. Great! I believe we are getting close to finalizing the specs for this
    task.

    What about the Admin Interface where we are going to allow Manage the
    actual subscriptions - do you agree with what I have proposed in my
    original post?

    DA.

  5. About admin interface:

    I think, that we need to allow to enter all fields from table (except
    eventid) there. I don't see any user-friendly interface to do it, since we
    also got ItemId and Prefix fields there, which can't be selected from any
    selector and needs to be typed manually.

  6. I was thinking about this Event Subscription part lately, particularly about
    Admin interfaces.

    After going through the goals of this whole task I believe we can start with
    simple Admin interface as described Alex "allow to enter all fields from
    table (except eventid)". Later, we can make decisions on improving these
    interfaces, but at least we'll have a core functionality for subscriptions.

    Please let me know your thoughts and I am calling for a task here if we are
    on the same page.

    DA.

  7. New ideas here:

    Add following fields to *Events* table:

       - BindToSystemEvent (text in format "unit-config-prefix:OnSampleEvent")

    Create table: *EmailEventSubsribers*:

       - SubscriptionId (auto-increment)
       - EmailEventId (from Events table)
       - SubscriberEmail (string default NULL, used in case if user subscribed
       without Registration - quite useful)
       - PortalUserId (from PortalUser table, default NULL)
       - CategoryId (from Category table, default NULL)
       - ItemId (default NULL)
       - SubscribedOn (int with DateTime Formatter)

    Then add processing code, that will be executed after processing kEvent
    from web-browser request.
    The code will look for current event signature prefix:event_name in
    Events.BindToSystemEvent table and if found then check if any subscribers
    should be informed about it. If so, then send this e-mail.

    On Fri, Feb 11, 2011 at 9:14 PM, Dmitry A. <dandre...@gmail.com> wrote:
    > PING

  8. There is minor TYPO in proposed table

    *EmailEventSubsribers* => *EmailEventSubscribers*

       - SubscriptionId (auto-increment)
       - EmailEventId (from Events table)
       - SubscriberEmail (string default NULL, used in case if user subscribed
       without Registration - quite useful)
       - PortalUserId (from Users table, default NULL)
       - CategoryId (from Categories table, default NULL)
       - ItemId (default NULL)
       - SubscribedOn (int with DateTime Formatter)

    Alex, would you please create the task for this outlining the Goals (we can
    use the ones I have described, but need some extension) and implementation
    plan.

    Cheers!

    DA

  9. New idea to add: is this the right place to also think about a "multi-
    newsletter system"?
    There's many websites now where you can manage your subscription to
    more than one newsletter, by using checkboxes in your account to
    updates your subscription. Of course these subscriptions could also be
    chosen on registration step.

    I'd also suggest here a text area when user decide to remove all
    subscriptions, to grab their feedback about their willing to
    unsubscribe.

    What do you think about this guys?

  10. Hi guys,

    Phil this sounds interesting, but I would say it needs a separate
    discussion topic. Current one is about a different type of subscriptions.
    Please feel free to fully describe your ideas in a new topic. Perhaps, some
    live examples would help.

    Alex, would you please create a task for our original discussion so it
    doesn't disappear among other topics! :)

    Cheers!

    DA

  11. Here is the task:

    INP-982 - Getting issue details... STATUS


  12. I have also created a separate task to cover the Admin Interfaces for
    managing User Subscriptions.

    *1243: Add new "User Subscriptions" section*
    *
    *

    INP-1017 - Getting issue details... STATUS

    *
    *

    DA

  13. one of most awaited task for me :)

    2 questions:
    - would this new feature also available for guest users (if coded in template to let guest choose the newsletter then can subscribe too)?

    - what do you think of having an optional "first name/last name" field for guest users? As they are in DB as other users, it could be really good from marketing point to know them better and write personally to them. Or why not all users fields, and being able to choose (for example, could be email address + country)  

    Envoy

  14. This is not newsletter or in any way related to current subscribers
    functionality despite having "subscribe" in it's name.

    Section Dmitry is talking about is a visual representation of "System Event
    Subscription" functionality (task

    INP-982 - Getting issue details... STATUS

    ), which allows a user/admin
    to subscribe to system events, e.g.:

       - new topic created in a category user is subscribed to
       - new topic is created in a sub-category of a category user is
       subscribed to
       - new post is created within a topic user is subscribed to
       - etc.

    If we manage to create proper subscriptions forms on front-end then user
    could actually subscribe to any system event (from a predefined by
    administrator list) that he need. This way you'll never miss a new reply in
    a topic you've posted to (like now in In-Bulletin).

    You are however talking about "Newsletter Subscriptions" stuff, when
    Administrator creates a set of newsletters and allows user to subscribe to
    them. Sort of mailing list functionality we have now. We need to check if
    it is working correctly and allow to subscribe to existing mailing lists.
    However each mailing results in creating new mailing list and we need to
    create newsletters list that would connect mailing lists and subscribers.

  15. Thanks for details here, I'll post in correct thread. However the topic seems very interesting anyway :)

    Envoy