[Feature Request] Email Event Subcriptions

[Dmitry Andrejev]

Hello guys,

Another idea crossed my mind which I think would be very useful to have.

1. We need flexible way of subscribing users to different types of actions. For example I wish to subscribe to receive an email when:

a. New TOPIC is added to the Forum Category (now TOPIC.ADD event triggered) so it's CATEGORY level subscription.

b. New POST is added to the TOPIC (now POST.ADD event triggered) so it's TOPIC level subscription.

c. New CATEGORY is added

d. Category is modified

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

Here is the first layout of this table.

Table: EmailEventSubscriptions

SubscriptionId (auto-increment)

PortalUserId (from PortalUser table)

EventId (from Events table)

CategoryId (from Categories table, default NULL)

ResourceId (default NULL) ???

Prefix (default NULL) ???

I am not sure if users should receive THE same email event - which I guess they should since it's all connected to it, but at the same time if we look at the sample with POST.ADD event that is Send to the TOPIC Owner - they can UN-subscribe from Event and it will never be triggered and our Events (for subscribers BCC) won't get it too.

Can you give me your vision of this?

Cheers!

DA.

[Alexander Obuhovich]

Please no ResourceId, because we are trying to get rid of it in another discussion and here you mention it again. Maybe, when email event is called we should pass any additional data, like:

• prefix involved;
• topic id;
• post id.

This way OnEmailEvent event can more accurately select group of people, who want to receive such notification.

--
You received this message because you are subscribed to the Google Groups "In-Portal Development Team" group.
To post to this group, send email to in-por...@googlegroups.com.
To unsubscribe from this group, send email to in-portal-de...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/in-portal-dev?hl=en.

--
Best Regards,

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

[Dmitry A.]

Yes, agree that ResourceId is not the best choice so let's leave it
out here.

Further more I think we need to make this even more flexible:

1. Ability to have Users to be signed up to ANY Events. While in most
cases these Events will have to added by hand (besides standard ones)
like new Event when users signed up to receive updates on Topic -
POST.ADD.SUBSCRIBERS . Again here we'll have to add a new Event.

Here we definitely need:

- PrefixId
- ItemId
- CategoryId ??? not sure

2. At the same time it would be nice to use the same table to create
list of Percipients who will be getting the same email as Primary
User. This will be managed in Admin (some special Grid).

As you can see the above two are different, but have similar storying
structure and I think we can add them both.

Let me know what you think.

On Jan 27, 11:05 am, Alexander Obuhovich <aik.b...@gmail.com> wrote:
> Please no ResourceId, because we are trying to get rid of it in another
> discussion and here you mention it again. Maybe, when email event is called
> we should pass any additional data, like:
>

>    - prefix involved;
>    - topic id;
>    - post id.

>
> This way OnEmailEvent event can more accurately select group of people, who
> want to receive such notification.
>

> > in-portal-de...@googlegroups.com<in-portal-dev%2Bunsubscribe@goog legroups.com>

[Alexander Obuhovich]

So it looks like additional tab on email event editing, called subscribers with grid of users. Each record could be edited to specify user and category, that action should apply to.

To unsubscribe from this group, send email to in-portal-de...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/in-portal-dev?hl=en.

[Dmitry A.]

Do you think it will work both ways then as I described in my prev.
post?

1. Subscribers can be added to ANY existing Event and limited by
CategoryId and ItemId + ItemPrefix (is last 3 are specified NOT Null)

2. New Events can created (in the future) with the same functionality
as Above.

Thus we would have:

Table: EmailEventSubscriptions

- SubscriptionId (auto-increment)
- PortalUserId (from PortalUser table)
- 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)

Let me know if this sounds right.

DA.