Open Closed

Extended Notification Defination. #7690


0
chekairi created

Hi,

Is there any way to extend notification definition class of notification system.

and another question is that we have three types of notifications 1. Push Notification 2. Email Notification 3. SMS Notification

so, is there any option that user can subsrcibe same notification of any one or two type? suppose that any user didn't want subsrcibe any one notification on SMS but they want to subscribe on email and push notification.

Thanks


4 Answer(s)
  • 0
    maliming created
    Support Team

    The current design cannot do this.

     You can use the settings system to save the user's notification settings, and send text messages and emails based on the settings when pushing real-time notifications.

  • 0
    BigCDogCrew created

    Has there been any change in this area over the last two years?

    This would be a very nice feature to have. We need certain notifications to be delivered by email and other to be delivered by SMS; but ultimately, the user should decide for themselves which or both methods they want to use for any given subscription.

  • 0
    ismcagdas created
    Support Team

    Hi,

    Yes, you can write your own notifier for sending emails , see https://aspnetboilerplate.com/Pages/Documents/Notification-System#real-time-notifications

  • 0
    BigCDogCrew created

    Thanks for the link. I have read that document a few times and it's starting to make sense, but there is still a missing piece of the puzzle in my mind.  How does the user decide which notification method will apply?  Consider the image attached below.

    If I am understanding correctly, all implementations of IRealTimeNotifier will be invoked by each notification. So, if we implement EmailRealtimeNotifier and SMSRealtimeNotifier and (signalR) WebRealTimeNotifier and PushRealTimeNotifier, then all of those classes will receive SendNotificationAysnc invocations for each and every notification created.   Correct?

    So, we would then have to include logic in each one of those notifiers to look up the user's notification subscriptions and check to see if that method of notification is appropriate or not.  Correct?  This would result in querying the database four times for each notification to retrieve the user's subscription choices.

    Would it not be best to have the publisher/distributor perform this configuration query once and then only invoke the specific IRealTimeNotifier(s) that are desired by the user for that specific type of notification? Or, alternatively...pass the subscription information to the IRealTimeNotifier as an input parameter so the notifier can use it without looking it up.

    At the root of this problem is the fact that not all notifications are created equal.  Some are informational and some are critical.  Some occur seldom and others occur frequently.   Users have to decide which method of notification is best for each specific type of notification.

    In this example below, my user is not that much concerned about new user registration.  They want to see those notifications when they login to the website, but they don't want to be bothered by email or sms for new users.   However, when a new product is created, they want to be informed immediately by SMS and also receive an email with the details that they can easily archive for future reference.   They are not too concerned about new product settings, but want to receive an email so they can archive those settings for future reference.

    BTW... I am NOT advocating radio buttons.  This image below is just a visual aide to help explain the problem.  The actual UI for selecting methods would need to allow for a substantially large number of options.