Notification -> NameTracker, allow Interest to target NameTracker

[nimmolo]

This is a place to keep track of a discussion Jason and I started about how to harmonize the use of Interest, Notification and QueuedEmail in MO. Notifications are like interests, but only used to track the use of Names on MO.

Jason's proposal:

First PR:

• Update the app wherever it checks notification.flavor and Notification.where(flavor: — just remove the checks
• Drop column notifications.flavor - they are all "1", "name".

Second PR:

• Rename the table from notifications to name_trackers
• Add a record to Interests corresponding to each record in NameTracker

class RenameNotificationsToNameTrackers < ActiveRecord::Migration
  def self.up
    rename_table :notifications :name_trackers
    NameTracker.find_each do |n_t|
      Interest.create!({target_type: "name_tracker", target_id: n_t.id, user_id: n_t.user_id, state: 1, updated_at: n_t.updated_at})
    end
  end
  def self.down
    rename_table :name_trackers :notifications
    Interest.where(target_type: "name_tracker").delete_all
  end
end

• Rename the class from Notification to NameTracker, update calls to Notification throughout the app
• Add NameTracker to Interest.all_type_tags and maybe a validator for Interest.target?
• Have the "Email Tracking" form create an Interest at the same time as the NameTracker with an association between the two
• Maybe be sure that deleting an Interest targeting a NameTracker deletes the NameTracker, too.

Then Interest becomes the front point for all such requests for notifications, but the polymorphic relationship remains strict (there is still an actual object pointed to for the name-tracking notification request). Interest itself doesn't need to hold any information that isn't required by all notification requests. We still have a place to store details like note_template and require_specimen (in the NameTrackers table). It allows additional "flavors" of trackers to be created in the future, each corresponding to a new table in the database and ActiveRecord model class. I think we could do away with notifications.flavor column, then. Otherwise the database doesn't change!

How notifications currently work:

The user goes to a name page, and on that page they select "Email Tracking". This takes them to a form inquiring details about how they would like to be notified and if they want an automated notification sent to the observer who posts an observation of that name (for example, asking for a specimen). They save that form and it creates a Notification with all that detail. There are no QueuedEmails yet. When another user posts an observation with an initial name you are tracking, or its consensus name changes to that name: This triggers the Notification. The Notification, in turn, creates two QueuedEmails -- one to the researcher, one to the observer. The QueuedEmail to the observer will have the custom note template attached, pulled from notifications.note_template.

[nimmolo]

EDIT: Well, that was fun. I didn't know about polymorphism.

Disregard the following:

I think it would be good to convert the interests.type_tag column to an enum.

Or rather, what i'd rather do for safety is copy interests.type_tag to a new interests.flavor column, converting the values to enum values, and check for stray values. Then drop the interests.type_tag column and make type_tag an instance method of Interest that converts flavor to a symbol. That way we don't have to change any methods in controllers. (Enums store integers but return strings — not symbols!)

The migration might be like this:

class InterestTypeTagToFlavor < ActiveRecord::Migration
  def self.up
    add_column :interest, :flavor, :integer
    change_column_default :interest, :flavor, nil
    Interest.update_all(flavor: "integer USING (CASE type_tag WHEN 'observation' THEN '0'::integer WHEN 'name' THEN '1'::integer WHEN 'location' THEN '2'::integer WHEN 'project' THEN '3'::integerWHEN 'species_list' THEN '4'::integer END)")
  end

  def self.down
    drop_column :interest, :flavor
  end
end

class Interest < AbstractModel
  belongs_to :target, polymorphic: true
  belongs_to :user

  # Do not change the integer associated with a value
  enum flavor:
       {
         observation: 0,
         name: 1,
         location: 2,
         project: 3,
         species_list: 4,
         name_tracker: 5  # ahead of the game
       },
       _suffix: :flavor