Impliment feature allowing User to granularly control their notification preferences.

[stevepolitodesign]

I'm thinking it would be helpful to add a feature that allows a User to control if and how they receive a Notification. For example, a User may want to receive both an email and sms Notification when they are mentioned in a Comment, but they may only want to receive an email Notification when they receive a reply to a Comment.

Twitter's notification settings is a good example:

CleanShot.2021-07-13.at.16.03.34.mp4

Below is a high-level approach outlining one possible solution. This is by no means the proper solution, but more of a demonstration.

# db/migrate/xxx_add_notification_settings_to_users.rb
class AddNotificationSettingsToUsers < ActiveRecord::Migration[6.0]
  def change
    add_column :users, :notification_settings, :jsonb, default: {}
  end
end

class User < ApplicationRecord
  # Types of notifications that a User can receive
  # such as being mentioned in a comment or followed by another User.
  # This will allow us to add more in the future.
  NOTIFICATION_TYPES = %w[mention new_follower].freeze

  # The ways in which a User can be notified
  # such as via email, text or in-app.
  # This will allow us to add more in the future.

  NOTIFICATION_MEDIUMS = %w[email sms in_app].freeze
  
  # Loop through all notification types and mediums
  # and combine into an easy to understand string.
  # 
  # => notify_of_mention_by_email
  # => notify_of_mention_by_sms
  # => notify_of_mention_by_in_app
  # => notify_of_new_follower_by_email
  # => notify_of_new_follower_by_sms
  # => notify_of_new_follower_by_in_app  
  NOTIFICATION_SETTINGS = []

  NOTIFICATION_TYPES.each do |notification_type|
    NOTIFICATION_MEDIUMS.each do |notification_medium|
      NOTIFICATION_SETTINGS << "notify_of_#{notification_type}_by_#{notification_medium}"
    end
  end
  
  # Use items in NOTIFICATION_SETTINGS as accessors
  # on the notification_settings column
  # 
  # => User.first.notify_of_mention_by_email
  # => User.first.notify_of_mention_by_sms
  # => User.first.notify_of_mention_by_in_app
  # => User.first.notify_of_new_follower_by_email
  # => User.first.notify_of_new_follower_by_sms
  # => User.first.notify_of_new_follower_by_in_app  
  store :notification_settings, accessors: [ NOTIFICATION_SETTINGS ]
end

[stevepolitodesign]

One problem with this approach is that it will mean we define a Notification in two places. I'm guessing we'll still want to leverage the existing namespacing via rails generate noticed:notification CommentNotification and just define NOTIFICATION_TYPES via any class that inherits from Noticed::Base.

[excid3]

One of the problems is lazy loading makes it hard / unreliable to find any classes that inherit from a class or include modules. It's most reliable if we traverse a directory.

And yeah, there are two main combinations that we'll have to support any combination of: the delivery method and the notification.

[excid3]

One option would be a model like so:

class NotificationSubscription
   belongs_to :owner, polymorphic: true

  # subscribed:boolean
  # delivery_method:string (ie. Twilio)
  # notification_type:string (ie. "CommentNotification")
end

That would allow:

• Users to enable / disable any combination of notification or delivery method
• Generating default subscriptions when a user is created
• Easy querying when delivering notifications

You could also probably do this with a json(b) column and have one record per user as well, but it might be a bit harder to organize.

[stevepolitodesign]

The NotificationSubscription approach seems less brittle and less bloated than storing everything in one jsonb column on the Owner model, and is probably the most flexible solution.

Questions

• Should we add a uniqueness contraint on the delivery_method and notification_type columns to prevent an Owner from having more than one NotificationSubscription per combination of delivery_method and notification_type?
• Is it even worth having a subscribed column? I tend to think it is worth having this column, but figured I would pose this question. Maybe the default should be that if a NotificationSubscription record does not exist for a combination of delivery_method and notification_type then the Owner is not subscribed.
• Should we enforce that the notification_type actually exists?
• Should we enforce that the delivery_method is actually enabled?
• Does the gem currently provide an interface to traverse all the Notification classes and delivery methods? I only ask because it would be nice to have some type of interface to render a form with all possible combinations of delivery methods and notifications.
• Should we provide an interface for dynamically creating methods on the Owner that will help get and set NotificationSubscription records? Something like current_user.subscribed_to_comment_notification_via_email? and current_user.subscribed_to_comment_notification_via_email=. This would just be a wrapper around querying for or creating a NotificationSubscription.

[stevepolitodesign]

Possible Drawbacks

• How do we prescribe creating a NotificationSubscription record(s) for each possible combination of delivery_method and notification_type? These records will probably need to be automatically created for each Owner, otherwise, how would an Owner be able to control their preferences?
• An additional query would need to be made each time we need to check if an Owner should receive a Notification. If this data was stored on the Owner model, we would not need to make that extra query.

[excid3]

I think we're going to rename Notification to Notifier and use Notification as the database model name to reduce confusion. I'll try and refer to them as Notifiers now.

• Yeah, probably need that so we don't have duplicates
• I think so? The reason being if you have a record, the user chose it. Absence of a record means the user's on the default value.
  This is how I keep track of the different states of forum subscriptions. If you didn't post in the thread, you're not subscribed. If you participated, you're subscribed. If you opted out, we add a ForumSubscription record with optout: true. If you haven't participated but subscribed to the thread, we create a ForumSubscription with optout: false. Then we can use those combinations to determine who to notify. Kind of similar concept here, although it may be too much?
• I don't think you need to verify the notification_type exists. You can add/remove types and those old records won't matter much. The dev will be responsible for deleting those NotificationSubscriptions for notifiers they remove though.
• Same for delivery_method? I just don't want to be too strict because it can make gems harder to maintain.
• No way to traverse right now, but we can simply enumerate the files in the notifications directory to get those.
• I think we can add helper method(s), but we'd want to keep them more simple:

Something like:

def subscribed_to_notification?(type:, delivery_method:)
end

Or... this might make more sense on the Notifier which would be a bit more direct?

class CommentNotifier < Noticed::Base
  deliver_by :database
  deliver_by :email, enabled_by_default: true
  deliver_by :twilio, enabled_by_default: false
end

CommentNotifier.user_subscribed?(user, delivery_method: :email)
#=> true
CommentNotifier.user_subscribed?(user, delivery_method: :twilio)
#=> false
CommentNotifier.user_subscribed?(user, delivery_method: :any)
#=> true

Probably need to add values to the Notifier themselves for each delivery method like the enabled_by_default above.

[stevepolitodesign]

Adding inspiration here:

• Forem
• GitLab