-
Notifications
You must be signed in to change notification settings - Fork 108
feat(email): reinstate account verification reminder emails #2990
Conversation
\o/ |
e8a7942
to
1f7d55d
Compare
<tr style="page-break-before: always"> | ||
<td valign="top"> | ||
<h1 style="font-family: sans-serif; font-size: 21px; line-height: 29px; font-weight: normal; margin: 0 0 11px 0; text-align: center;">{{t "Hello again."}}</h1> | ||
<p class="primary" style="font-family: sans-serif; font-size: 14px; line-height: 21px; font-weight: normal; margin: 0 0 21px 0; text-align: center;">{{{t "A few days ago you created a Firefox Account, but never verified it. A verified account lets you access your tabs, bookmarks, passwords and history on any device connected to it. Simply confirm this email address to activate your account."}}}</p> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I recommend this copy instead of the current paragraph:
You recently created a Firefox Account but haven't confirmed your email yet. Confirm your email so that you can start using Firefox Sync, Pocket, Lockbox, Firefox Send, Monitor and more.
Make sure "Confirm your email" is in bold. This is the main call to action that matches the button.
CC @ryanfeeley
The copy was very Sync specific. I've made it shorter and a bit more generic. I'm also trying to eliminate synonyms that were used interchangeably (i.e. verify, confirm and activate). This will make things less confusing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@davismtl, regarding the part in bold, that is going to cause problems for localisers. Word order etc are obviously completely different depending on language, so we can't just split the sentence up and assume that the bold part is always supposed to be before the non-bold part. In some languages it will be in the middle or at the end or possibly even split apart in more than one place.
If you can rework the copy so that we're breaking things up into full sentences, that would work, or if you want to keep that copy and lose the bold, that's fine too.
(alternatively, @shane-tomlinson / @vbudhram, if there are clever markup tricks we can employ to work round this, let me know)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(for now I've just ditched the bold, but someone shout at me if I should do something else)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The template here renders the string using a {{{t
, so you should be able to use a <b>
or <strong>
HTML element within the string. Ugly, but I think it should work? Localizers don't mind HTML as long as there's not too much.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As mentioned in IRC, I don't think that's an improvement. Going to merge this as is, but you're welcome to change it as a follow-up if you feel strongly about it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @philbooth, this looks good overall, I just had a few questions/comments.
@@ -14,7 +14,9 @@ const validators = require('./validators'); | |||
|
|||
const HEX_STRING = validators.HEX_STRING; | |||
|
|||
module.exports = (log, db, mailer, config, customs, push) => { | |||
module.exports = (log, db, mailer, config, customs, push, verificationReminders) => { | |||
const REMINDER_PATTERN = new RegExp(`^(?:${verificationReminders.keys.join('|')})$`); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You could export the regex directly from verificationReminders
or put into the validators lib.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm minded to keep this where it is because it's local to this module and conceptually it seems like the right place. Exporting it from lib/verification-reminders
pollutes that module with knowledge about the API surface and putting it in the validators lib would force that to import lib/verification-reminders
.
}); | ||
const route = getRoute(accountRoutes, '/recovery_email/verify_code'); | ||
|
||
afterEach(() => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice cleanup 👍
1f7d55d
to
a9898d4
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall, this looks good @philbooth, I left a few comments about areas I find confusing.
There is one case I'm wondering how we'll handle, the case of a deleted account. This can happen if a user signs up, never verifies, then signs up again with the same email address. The original account will be deleted. I imagine it should be fine since you won't be able to get the email address for the uid, but want to point out that it's possible and should be accounted for in the script that does the sending.
a792d8d
to
5e536d4
Compare
473cd0e
to
e9bcdec
Compare
ddcc65a
to
28094c0
Compare
Removing the I've been using these steps to test the script locally end-to-end:
You should then see the reminder emails turn up in your inbox (or the link will show up in the mailer log if you're doing it that way). This is what the first email looks like rendered: And this is the second one: @mozilla/fxa-devs r? |
cbf9e6c
to
d3b26f4
Compare
I double-checked the markup against the docs, ran it through the validator, still no luck. The only thing occurring to me at the moment is whether it might be related to the MIME-encoding we use in the email service. I've noticed the emails where ViewActions work for me are all 7bit encoding, whereas we use base64. I can have a play with the email service at some point to see if that fixes it but regardless, that won't be in this PR. |
Another possibility that occurs to me is it could be because the emails are being sent from a |
Another thing I just noticed, our emails have |
Putting a |
@philbooth can you just make the following text in the body bold? Confirm this email in the first email and Confirm this email address to activate your account in bold for the second email |
@davismtl, see the note and question above about bold text and localization: |
@philbooth ahh, that makes sense. Thanks for clarifying. How about we make the sentences that start with "Confirm" their own paragraphs so that the call to actions stand out rather than being part of the larger paragraph? |
Yep, that works, will update the PR. |
0e53262
to
d8acc65
Compare
d8acc65
to
042547a
Compare
042547a
to
a326c28
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@philbooth This test locally and it runs pretty well 👍🏽. I have just the one question about including service name but I think that can be done in a follow up issue.
|
||
<body style="-ms-text-size-adjust: 100%; -webkit-text-size-adjust: 100%; margin: 0; padding: 0;"> | ||
|
||
<script type="application/ld+json"> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🎉
@@ -279,6 +279,8 @@ module.exports = (log, db, mailer, Password, config, customs, signinUtils, push) | |||
tokenVerificationId: tokenVerificationId | |||
}); | |||
} | |||
|
|||
return verificationReminders.create(account.uid); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This might be a can of worms, but should we store the verification link with the redirectTo, service, etc? If we do this, then it will be possible for those users to get linked to the right verification page for the service.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's a valid suggestion but the code I'm reinstating didn't behave that way and it's too late in the train to implement it now. The choice is to ship on train 134 without that or delay the feature for two weeks.
These changes now have been addressed and an r+ was given in Slack.
Fixes #2939.
Adds logic for creating, deleting and processing account verification reminders, which was removed because of MySQL-related complications in #2283. The implementation here depends on Redis sorted sets instead of MySQL, which were added to
fxa-shared
in mozilla/fxa-shared#65.The code here works and has tests, but it's still marked
WIP
because I haven't written the script for thefxa-admin
node yet. Opening in case anyone wants to cast an eye over it or offer feedback while I finish that off.Also note there is an unresolved question about the copy for the emails, since they still mention "a few days ago..." and "a week ago..." but the actual intervals are now 1 day and 5 days. Presumably we're going to fix the copy rather than the intervals.