Repository: mdn/kuma

Issue:
Allow user to opt-in to MDN news and promotional emails
# User story
As a user, I want to be able to opt-in to emails about MDN news and promotions, so that I can be up to date on what's happening on MDN if I choose.

# Acceptance criteria

- [ ] Display checkbox on Create MDN Profile page
- [ ] Display checkbox on MDN Profile page (in personal section)
- [ ] If this option is checked on the Create MDN Profile page, this is reflected on the MDN Profile page after the account has been created
- [ ] This option is stored as a flag in the db that we can reference when sending out emails
- [ ] check box copy says: "Get updates on what’s new with MDN to your inbox."

# Tasks

- [x] Finalize copy (Kadir)

# Design

Create MDN Profile Page:
InVision: https://mozilla.invisionapp.com/share/Y8SGMKQBCW3#/368129372_Create_Account_-_MDN_Profile
Zeplin: https://zpl.io/2jYxqKp

Profile Page (personal section):
InVision: https://mozilla.invisionapp.com/share/Y8SGMKQBCW3#/372750124_Account_-_Profile_-_Filled
Zeplin: https://zpl.io/adN5yJE



Discussion:
To be continued in next sprint.
I am going to transfer this issue to Kuma or else I am totally going to forget about it ;)
Hey @escattone,

Should I add a newsletter checkbox to the current sign-up form, I assume there is some back-end work that needs to happen before the data will actually be handled properly correct?

Is this work blocked on https://github.com/mdn/kuma/issues/5792 or, does it makes sense to do the front-end work but, hide it behind a Constance setting?

Thanks!
> Should I add a newsletter checkbox to the current sign-up form, I assume there is some back-end work that needs to happen before the data will actually be handled properly correct?
> 
> Is this work blocked on #5792 or, does it makes sense to do the front-end work but, hide it behind a Constance setting?

I think @Gregoor is taking this work on the back-end, so he'll have the final word, but I think you could go ahead and add a checkbox to the current sign-up form, but include/exclude it based on a simple `python-decouple`/environment variable in `kuma/settings/common.py`, something like:
```python
ENABLE_NEWSLETTER_SIGNUP = config('ENABLE_NEWSLETTER_SIGNUP', default=False, cast=bool)
```
that you'll then have access to `settings.ENABLE_NEWSLETTER_SIGNUP` in the Jinja template.
Thanks, @escattone. That was my thinking as well. Total tangent but, now I hear you speak of a third mechanism for these things 🙈 😸 

I get that Constance is essentially an on-off switch and Waffle is an on-off switch on low-grade steroids ;p Where does `python-decouple` fit into this picture? i.e. when should we use which option?

The distinction between Constance and Waffle seems clear to me, but what is the difference between Constance and `python-decouple`?
@schalkneethling I don't see it in the invision deck, the language of the check box has to be changed, it's now: "Get updates on what’s new with MDN to your inbox."
> @schalkneethling I don't see it in the invision deck, the language of the check box has to be changed, it's now: "Get updates on what’s new with MDN to your inbox."

Hmmm, that reads a little odd to me. How about:

`Get updates on what’s new with MDN delivered to your inbox.`

or,

`Get updates on what’s new on MDN delivered to your inbox.`

Thoughts @atopal?
That's the wording proposed by our legal counsel. I do like yours a bit better, Schalk, and would normally just go with that, but I don't think it's worth holding back and the several day long back and forth with legal to optimize that.
@schalkneethling 

> I get that Constance is essentially an on-off switch and Waffle is an on-off switch on low-grade steroids ;p Where does `python-decouple` fit into this picture? i.e. when should we use which option?

I think a `python-decouple`/environment variable (i.e., something like `ENABLE_NEWSLETTER_SIGNUP = config('ENABLE_NEWSLETTER_SIGNUP', default=False, cast=bool)`) is the best option going forward, certainly for anything that changes infrequently (perhaps on the order of once a month at most?). On the one hand, it's much simpler (no dependencies other than the very simple `config` from `python-decouple`) and faster (the code references a simple variable rather than making calls to the Redis cache and/or the database to get the value on every request). On the other hand, changing the value involves submitting an infra PR to change a setting (simple though) and then deploying, which isn't a big deal but definitely more involved than changing the setting via the Django admin console.

I'd like to avoid using Waffle or Constance going forward, mainly because it doesn't really fit with the future [JAMStack](https://jamstack.org/) approach of Yari/Stumptown, but there may be specific use cases where it still makes sense.


Thanks so much for the detailed feedback @escattone, much appreciated!

Resolving patch:
diff --git a/kuma/settings/common.py b/kuma/settings/common.py
--- a/kuma/settings/common.py
+++ b/kuma/settings/common.py
@@ -1792,6 +1792,9 @@ def get_user_url(user):
 NEWSLETTER = True
 NEWSLETTER_ARTICLE = True
 
+# Newsletter Signup Settings
+ENABLE_NEWSLETTER_SIGNUP = config('ENABLE_NEWSLETTER_SIGNUP', default=False, cast=bool)
+
 # Content Experiments
 # Must be kept up to date with PIPELINE_JS setting and the JS client-side
 #  configuration. The 'id' should be a key in PIPELINE_JS, that loads


Test patch: