WIP:Add a welcome email

[Flaburgan]

So as discussed on discourse, this pull request adds a welcome email sent to the users once they filled the first form (with email and username). I only put the very basics in it, here is how it looks:

Subject is "Welcome aboard!"
Body:

You now are a member of the diaspora* community!

https://diaspora-fr.org is the diaspora* server (called a pod) where you registered. Log in there using your username, testwelcomeemail14. Once logged, you will be able to reach the whole diaspora* network, even users registered on other pods.

Your diaspora* id is testwelcomeemail14@diaspora-fr.org, share it with everyone so they can find you in the network.

If you need help, have a look at the tutorials or the help section. If you don't find anything, then post a public message with the #question tag so people can help you.

Welcome aboard, enjoy diaspora*!

@goobertron I'd love some feedback on the content, and what we could write.

I also still need to add links to the tutorials and help section text.

I guess I also need to write some tests...

[jhass]

I guess in light of the recent PGP bugs, more of our target audience switched to plain text only mails, so I think we should take care to provide a variant there :)

[Flaburgan]

I thought about that, but this email is sent right when the user register so he didn't set any email preferences. How one does set that btw?

[jhass]

The preference is within the mail client. We send a MIME multipart message with two parts, one being HTML one being plain text. As for the Rails side it should be just adding the plaintext template and adding it to the render call iirc.

[Flaburgan]

Oh okay, I'll do it then. Should be done this afternoon.

[goobertron]

Thanks for the ping. I'll look this over in the next day or two.

[goobertron]

OK, I've had a look at the text. I think we should mention diaspora* in the email subject. I've also worked on the grammar and tried to make the message as clear as possible while remaining friendly and welcoming. I've also added a link to the tutorials and explained how to find the in-app help.

      subject: "Welcome to the diaspora* community!”
      member: “Congratulations! You now are a member of the diaspora* community!"
      part_of_network: “You have registered with %{pod_url}, one of the many nodes (called a “pod”) in the diaspora* network. To access the diaspora* network, you will need to sign in to that same pod using your username, %{username}, and password. Once signed in, you will be able to reach the whole diaspora* network, even people registered with other pods."
      your_id: "Your diaspora* id is %{id}. This includes your home pod name and helps diaspora*'s software to locate you in the network. Share this with everyone you want to connect with in diaspora*."
      help: "If you need any help, have a look at our %{tutorials_link} or the in-app help section, which can be found by via the user menu in the header bar. If you don’t find the information you need there, post a public message with the #question tag so that members of our amazing community can help you."
      tutorials_link_text: "tutorials for new community members"
      welcome: "Welcome aboard, and enjoy diaspora*!”

You'd then need to line 9 of app/views/registrations/welcome_email.haml to:

!= t("registrations.welcome_email.help", tutorials_link: link_to(t("registrations.welcome_email.tutorials_link_text"), "https://diasporafoundation.org/tutorials")).html_safe

(I think that's correct syntax, but do check it.)

I welcome comments on what I've done.

[SuperTux88]

I set the milestone to the next major for this PR, because I think this new welcome mail isn't really compatible with the already existing optional welcome message. When we now add a non-optional additional welcome mail, users on pods where the optional message is enabled would receive two mails (one notification mail for the PM, and the new welcome mail), and I think that's too much (at least I as a user would be already annoyed when I would receive two different welcome messages).

There are multiple possibilities to solve this:

1. Only send the new welcome mail when the optional message is disabled (that would be compatible with a minor release, but wouldn't solve the problem of users forgetting their username on pods where the optional message is enabled).
2. Add a note to the changelog for next major, so podmins can disable or change their own welcome message.
3. Remove the optional welcome PM with the next major release.

Point 3 would allow some more options to replace the old welcome message better:

1. Make the new welcome mail customization (Include an optional "some words from your podmin" section?).
2. Send the new welcome mail as PM if the pod doesn't have mails enabled (that wouldn't solve the problem of users forgetting their usernames on pods without mails, but I think that can't be solved on pods without mails anyway ... but it would replace the old welcome-message on pods without mails ... maybe only do this if the welcome message contains "some words from your podmin" from the last point?)

What do others think?

[goobertron]

Hmm, that's a good point.

Given that the current default of the optional welcome message is so bare, could we replace it with this new one? That would mean that new users would get the new, better welcome message as a PM, and get just one email notification if email has been enabled (and if they have registered a valid email address).

I don't know if a more complex message with links in it as I've suggested is compatible with the yml file.

My suggestions would be:

• Make this either non-optional or optional but with the default set to enabled.
• I'd like it to be configurable/editable by the podmin, but this means it wouldn't be localised.
• I like your idea to add an optional 'message from the podmin' at the end of the text. If the podmin adds a message to their diaspora.yml file, this would be added to the welcome message in the language they choose. That way, at least most of the message would be sent in the user's chosen language.
• The 'optional' setting in diaspora.yml would be just for the podmin's extra message, not for the new welcome message. (In which case, I would remove the default message text from diaspora.yml.example, as it is not needed.)

This would combine your options 2 and 3: we add a note to the changelog so that any podmins who have set an optional message have a chance to alter it to fit better with the new welcome message in this PR. However, no podmin would need to alter the enabled setting in yml, as that would be only for their own message. That should hopefully minimise the possibility of things going wrong when this is introduced.

[SuperTux88]

That would mean that new users would get the new, better welcome message as a PM, and get just one email notification if email has been enabled (and if they have registered a valid email address).

Fla wants to send this as Mail and not as PM, so users have a mail containing their username and pod URL for the case they forget this. A PM wouldn't work then, so I would only send the PM if email is disable on the pod.

This would combine your options 2 and 3: we add a note to the changelog so that any podmins who have set an optional message have a chance to alter it to fit better with the new welcome message in this PR.

Yes, that's more or less what I was thinking about. That way we can include the advantage of the old message (customizable by the podmin) with the new, translatable and better mail. And we can safely remove the old PM, so people don't receive two messages.

[Flaburgan]

Looks like we have a consensus ;)
I'll try to work on it next week.

[Flaburgan]

After a discussion on discourse, it looks like this e-mail message is also a good place to verify the ownership of the e-mail address. So it should include a verification link, and we should not fill the user object's "email" property but the "unconfirmed_email" property when someone is registering. That means a new user will not receive any email from diaspora* (except the welcome one) as long as he didn't verified it (so no usurpation and no hardbounce).

[SuperTux88]

we should not fill the user object's "email" property but the "unconfirmed_email" property when someone is registering.

No, you need to set an email, because it is NOT NULL. But you should set disable_mail to true until it is confirmed.

[Flaburgan]

Oh, we have a disable_mail property? Didn't know that. Isn't that a bit overcomplicated?

I know users who put a wrong email on purpose when signing in because they want to remain anonymous, the email field could become optional imo. And that means email should not be NOT NULL any more. But we're getting out of scope for this PR.

[goobertron]

Perhaps (getting very out of scope for this PR) if a user enters a non-existent email address, we could do the following:

The first time a mail notification is sent, and bounces back with an 'address not known' error, send the user a PM (but not an email confirmation, of course) to inform them that the email address was not recognised, and give them three options:

1. Correct the email address stored in the account (in case they had entered it incorrectly);
2. Retry an email to that address (possibly the receiving mail server was down when the notification was sent);
3. Continue to store this email address in the account but not send email notifications.

As I said, not for this PR but a possible idea for the future.

[denschub]

• Let's make eMail address validation part of this, so that the welcome mail also includes the validation link (Devise supports that!)
• Needs a plain text version
• We should also remove the welcome private message feature then, there is no need to send two mails.
• Some language feedback was provided.

[MasterOfTheTiger]

@denschub

We should also remove the welcome private message feature then, there is no need to send two mails.

This should still be an option for those who want to use that.

[SuperTux88]

No, as @denschub already said, there shouldn't be sent two mails after signup, and there is also no need to do so, the one should be good enough to cover everything.

[MasterOfTheTiger]

No, as @denschub already said, there shouldn't be sent two mails after signup, and there is also no need to do so, the one should be good enough to cover everything.

What about choosing one over another?

[goobertron]

The welcome mail will be sent when someone signs up, before they've had chance to set preferences. The decision to send one email automatically is a good one, in my opinion.

I notice that I previously added mentions of the tutorials and in-app help to Fla's email text; as these features will be merged into the new guides, that text (and the link) will need to be updated.

[MasterOfTheTiger]

@goobertron

The welcome mail will be sent when someone signs up, before they've had chance to set preferences. The decision to send one email automatically is a good one, in my opinion.

I know that. I misstated. What I was saying is that the podmin should be able to decide (in diaspora.yml) which version he or she wants to use. I personally like the direct message, that way they can easily respond to me with questions (which has happened on a few occasions).

[SuperTux88]

What I was saying is that the podmin should be able to decide (in diaspora.yml) which version he or she wants to use.

Since it's going to be used as email validation, private message won't work for that, so it needs to be email. And we still shouldn't spam the users with two mails.

I personally like the direct message, that way they can easily respond to me with questions (which has happened on a few occasions).

As said, the new welcome email should cover all things needed to replace the old message, and for example to be able to answer we can just set the podmin_email as Reply-To, so people can still reply to the podmin, which would even become handier later if there is a problem with the pod (down, expired SSL, or something else), so people can contact the podmin, even if they can't access their private messages anymore (and also can't get the podmin email from the sidebar, if the pod is down, and they didn't save it somewhere).

[weex]

Typo in the current text: "Once logged" should be "Once logged in"

[Flaburgan]

To simplify the changes on the codebase and for the podmin, I was wondering about another option, could we keep the welcome PM by the podmin, but simply disable the e-mail notification for that specific PM? That way, we don't have to change anything for the podmin, and the users don't receive two e-mails.

[Flaburgan]

Typo in the current text: "Once logged" should be "Once logged in"

Fixed, thanks. I also fixed @jhass remarks about Log in -> Sign in.

[denschub]

but simply disable the e-mail notification for that specific PM?

How would you implement that?

[SuperTux88]

I don't like that there are two different messages, even if the podmin PM wouldn't also send an email notification. Can't we just combine both of them to just one single email/message, so the podmin message is also included there and we could set the podmin contact mail-address as Reply-To in the mail so people could still answer to this message to get in touch with the podmin?