GET /profile/notifications writes to the database

Summary

Visiting /profile/notifications causes Rails to attempt to write to the database. On a Geo secondary, this fails with ERROR: cannot execute INSERT in a read-only transaction. When the database is readonly for other reasons, this will also fail.

Steps to reproduce

• Sign into a Geo secondary
• Visit /profile/notifications

What is the current bug behavior?

ERROR: cannot execute INSERT in a read-only transaction

What is the expected correct behavior?

The notifications page

Possible fixes

Relevant part of the backtrace:

  activerecord (4.2.10) lib/active_record/persistence.rb:250:in `update'
  app/models/user.rb:1041:in `global_notification_setting'
  app/controllers/profiles/notifications_controller.rb:6:in `show'

So this method in app/models/user.rb needs to change:

  # Lazy load global notification setting
  # Initializes User setting with Participating level if setting not persisted
  def global_notification_setting
    return @global_notification_setting if defined?(@global_notification_setting)

    @global_notification_setting = notification_settings.find_or_initialize_by(source: nil)
    @global_notification_setting.update_attributes(level: NotificationSetting.levels[DEFAULT_NOTIFICATION_LEVEL]) unless @global_notification_setting.persisted?

    @global_notification_setting
  end

app/models/notification_setting.rb already has:

  default_value_for :level, NotificationSetting.levels[:global]

Perhaps we can just change this to be:

  default_value_for :level, NotificationSetting.levels[User::DEFAULT_NOTIFICATION_LEVEL] # :participating

instead? Or would this have wider implications?

It seems very strange for your user's notification level to start at global, then jump to participating if, and only if, you visit this page.

/cc @jramsay to consider scheduling.