Support for Opt-in by default? - mailkick


We are using mailkick in our Rails app to great effect and sound it to be a simple tool to add to our arsenal. However, with some recent privacy changes around the world but primarily here in New Zealand we now have the need to create an opt-in by default list, as we need to user's express permission first.

While we can reverse the logic in our code to mean the existence of an Mailkick::OptOut means they are actually opt-ed in, it's going to get really confusing really quickly, with high chance of accidental error, especially in production in the heat of the moment.

Therefore, looking at how "simple" the gem in (I mean no disrespect by that at all) we are considering duplicating some of the functionality: * creating a mailkick_opt_ins database table * adding a opted_in scope * adding a opted_in? method

Do you have any advice or plans to add support for this in the future? If you did a first-party solution you probably won't need 2 tables but we're wanting to keep things separate on purpose so we don't trample on each other's feet!

Thanks for all the hard work on myriad of gems, we use a lot of them and plan on using more in the future.

Thanks, Dave

Asked Sep 25 '21 22:09
avatar daveharris

3 Answer:

Hey @daveharris, thanks for the suggestion! I did some prototyping and think it makes sense for the 1.0 release, but don't have a timeline on when that'll be. I'm currently thinking:

class User < ApplicationRecord


create_table :mailkick_subscriptions do |t|
  t.references :subscriber, polymorphic: true, index: false
  t.string :list

add_index :mailkick_subscriptions, [:subscriber_type, :subscriber_id, :list], unique: true, name: "index_mailkick_subscriptions_on_subscrib

And subscribe(list)/subscribed?(list)/unsubscribe(list) for the high level design.

Answered May 18 '21 at 22:55
avatar  of ankane

Hi @ankane,

Yeah that's exactly what I had done in the end, turned out to be really simple.

The thing that makes the subscriptions (potentially) easier than opt-outs is the fact that you may not have to deal with list: nil which makes the DB logic a lot simpler!

Answered May 18 '21 at 23:29
avatar  of daveharris

Just pushed 1.0 with this change. Thanks again for the suggestion!

Answered Jun 04 '21 at 00:17
avatar  of ankane