Opt-ins working with Rogue

[katiecrane]

We need to figure out how #7292 will work with Rogue.

Questions:

• Should that data ultimately live in Rogue?
• Will it be sent from Phoenix -> Rogue -> Phoenix?
• Will that be a separate table in Rogue or live on the signup?

Currently we can't turn on sending signups from Rogue to Phoenix because we would be losing the opt-in information, which gets stored in the dosomething_signup_user_signup function after the signup is created. I'm trying to figure out the best way to get Rogue and the opt-ins to work together in this interim time when we are still posting everything back to Phoenix.

cc: @sbsmith86 @chloealee @weerd Tagging you Diego because you know the inside outs of the opt-in situation 😃

[weerd]

@katiecrane @sbsmith86 Howdy! Rogue doesn't currently need to worry about opt-ins. It lives as a separate table in Phoenix-Ashes. We planned it without the need for Rogue for the time being. Is this for like a future thing for Rogue, cause sure... eventually we'll want to store this in Rogue but not for the near future?

[katiecrane]

@weerd Awesome! So what will happen with Rogue signup collecting turned on is instead of calling dosomething_signup_user_signup, Phoenix will make a request to Rogue, which will save the data and then send it back to the Phoenix API so the signup lives in both places. So for now we'd need to add functionality to the Phoenix API to be able to grab those opt-in params from Rogue in order to save that data in Phoenix, and we'd have to handle passing those params along on the Rogue side. I'm wondering if that's what our approach should be?

[weerd]

So I think I'm missing some context.. so the larger plan is to start sending signups to Rogue? Can this not be approached how reportbacks were approached, and have the records be created in Phoenix first, but then send a copy over to Rogue? I think that would alleviate the need for the back and forth, and ultimately might make things easier when we burn Phoenix-Ashes and activate Phoenix-next fully, given that it'll just need to worry about receiving signups (and maybe confirming it was received or whatever) instead of coordinating back again with Phoenix to also save it there after the return trip? Thoughts?

[katiecrane]

@weerd Yes, we are starting to send signups to Rogue. This was approached in the same was as reportbacks, which was to intercept the reportback before it is saved in Phoenix, send it to Rogue and save it there, and then send it back to Phoenix. We don't save it in Phoenix before sending it to Rogue. That is why we would have to shuttle around the opt-in data.

[sbsmith86]

@weerd For reportbacks, we have been sending to rogue first, then sending back to phoenix. The idea was that this is what would make it easier when wanting to stop using phoenix to power the gallery and admin reviewing because all we would need to do is turn off the functionality in rogue that sends the reportback back to phoenix.

I don't see a huge drawback for signups to be stored in phoenix first before being sent to rogue. @katiecrane that might actually clear up the issue with needing to deal with failed signup request to rogue since phoenix can just work normally and we can deal with the failure on the backend.

[weerd]

Ah, ok. Then I was just confused as to how reportbacks were done. Cool. Well, either way I can build what I had planned and make sure it's all working, and then afterwards if you want to jump in and do the round-trip stuff between Phoenix & Rogue or just sending to Rogue after, that sounds good to me. 👍

The opt-in data definitely needs to get stored in the dosomething_campaign_affiliate_opt_ins table on Phoenix so that it can be exported as a CSV via the CMS, is all :) Once I'm done with the feature I can walk @katiecrane through the process of where/how everything happens with opt-ins, to help decide where Rogue can jump in.

[katiecrane]

@sbsmith86 oooo interesting...I'm a little worried that that could lead to Rogue and Phoenix not having the exact same data (I could see a case where stuff is weirdly failing to get to Rogue but saves okay in Phoenix), but definitely would make dealing with failures much better. I'd also have to double check if there's anywhere that it checks to see if a signup lives in Rogue and see if that would break that. We'd still have to figure out how to deal with failures in future Phoenix, but it would be okay for now.

@weerd Yup, I want to make sure all your functionality works as expected in the current world!

[sbsmith86]

it also sounds like we will still have to store this opt-in stuff in rogue at some point so we should keep that on our radar when it comes to migration and turning rogue on for real.

[katiecrane]

@sbsmith86 yup! should be easy enough to send over, we'd just need to decide how we want to store it. I'm guess it would be a mini migration after the big migration if we're not going to be sending the opt-in data over to Rogue from new signups yet

[weerd]

If it helps this is the schema for the dosomething_campaign_affiliate_opt_ins table, for helping decide how to store in Rogue; whether data is added to the signup record or a different table altogether...

[katiecrane]

Here is where we send the signup to Rogue, notice that we skip calling dosomething_signup_user_signup if Rogue is on because we do not want to store the signup in Phoenix.

However, that function is where we call dosomething_campaign_create_affiliate_messaging_opt_in to create the opt-in.

I think this could be solved by calling dosomething_campaign_create_affiliate_messaging_opt_in here to make sure we are still saving opt-ins when Rogue is on.