ee0a521a83
* Favoring delete_all on user relationships Prior to this commit, several of the user's "has_many" were marked as `depenedent: :destroy`. In the case of :destroy, ActiveRecord instantiates each object and then runs destroy. Whereas in the case of :delete, ActiveRecord issues a SQL command to delete the related files. It is often "safer" to use :destroy, as it guarantees that you'll instantiate the record and run it's callbacks. But sometimes you have to go with the speed of SQL. And while not directly related to #15424 it is representative of our callback ecosystem creating some unexpected computational loads. Related to #15442 and #15424 * Noting models that user no longer cascade destroys
27 lines
1 KiB
Ruby
27 lines
1 KiB
Ruby
module Users
|
|
# @note When we destroy the related user, it's using dependent:
|
|
# :delete for the relationship. That means no before/after
|
|
# destroy callbacks will be called on this object.
|
|
class NotificationSetting < ApplicationRecord
|
|
self.table_name_prefix = "users_"
|
|
self.ignored_columns = %w[email_connect_messages]
|
|
|
|
belongs_to :user, touch: true
|
|
|
|
validates :email_digest_periodic, inclusion: { in: [true, false] }
|
|
|
|
alias_attribute :subscribed_to_welcome_notifications?, :welcome_notifications
|
|
alias_attribute :subscribed_to_mod_roundrobin_notifications?, :mod_roundrobin_notifications
|
|
alias_attribute :subscribed_to_email_follower_notifications?, :email_follower_notifications
|
|
|
|
after_commit :subscribe_to_mailchimp_newsletter
|
|
|
|
def subscribe_to_mailchimp_newsletter
|
|
return if Settings::General.mailchimp_api_key.blank?
|
|
return unless saved_changes.key?(:email_newsletter)
|
|
return if user.email.blank?
|
|
|
|
Users::SubscribeToMailchimpNewsletterWorker.perform_async(user.id)
|
|
end
|
|
end
|
|
end
|