Invite workflow

[angelim (Alexandre Angelim)]

I’ve been thinking about the invite workflow and I have the following suggestions. Let me know what you think.

1. Invitees shouldn’t have to confirm email address. The only way they got to the forum was reading an undisclosed token in their email.
2. email_domains_blacklist should be used to validate invite emails. The inviter should know that email cannot be used.
3. We could create a notification when creating invitee accounts to instruct them to define username and password before leaving. That could avoid some confusion later on, when they try to login again.
4. Maybe we could send a different welcome message to invitee accounts, adding some information related to their condition. The password definition being one of them. Stating that they were referred and that is reflected in our trust and that their actions would also affect the inviter’s reputation. [welcome_invite already has a different template.]
5. The inviter should be able to invite more than one person at once. Maybe a email list separated by commas with a clear limit.[conflicts with 6]
6. The inviter could provide the invitee name when creating an invite. Starting the email with the inviter’s name may increase the likelihood of the invitees opening the email.
7. Use the inviter name instead of username in the email template and address. Invitees may not recognize the inviters username.
8. The private message(Welcome message) sent when the invitee accepts the invitation could be signed by the inviter, instead of the system. Aside from being more personal, the invitee is readily presented with the inviters account, making it easier for them to begin conversations inside discourse.

[Mittineague]

I’ve been thinking about the invite workflow and I have the following suggestions. Let me know what you think.

Invited people shouldn’t have to confirm email address. The only way they got to the forum was reading an undisclosed token in their email.
email_domains_blacklist should be used to validate invite emails. The inviter should know that email cannot be used.
We could create a notification when creating invite accounts to instruct them to define username and password before leaving. That could avoid some confusion later on, when they try to login again.
Maybe we could send a different welcome message to invited accounts, adding some information related to their condition. The password definition being one of them. Stating that they were referred and that is reflected in our trust and that their actions would also affect the inviter’s reputation.
The inviter should be able to invite more than one person at once. Maybe a email list separated by commas with a clear limit.
Ask for the invited name when creating an invite. Starting the email with the inviter’s name may increase the likelihood of them open the email. (conflicts with 5)

Use the inviter name instead of username in the email template and address. Invited people may not recognize the username.

All this only my opinion of course

1. Good idea as long as that’s the email address they want to use, or if they can change it.
2. Good idea, no point in sending an invite to someone only to have them not get in.
3. Excellent point When I invited some test accounts for the SitePoint site I didn’t understand how it worked and missing this led to some confusion. Once I knew what to do it was easy enough that it seemed obvious, but before I knew …
4. I was surprised when I learned my invitees were jumped straight to TL 2. I’m not sure the info is important as they’ll simply see more features. First I’ve heard about invitee misbehavior affecting the inviter.
5. While having a TL does imply a certain errmm level of trust, my “introduces potential abuse problems” flag gets raised.
6. That would be more “personable” and friendly.
7. I can’t say, I use the same for both.

[angelim (Alexandre Angelim)]

First I’ve heard about invitee misbehavior affecting the inviter.

I got that from one of @codinghorror posts. It’s most likely a manual process done by the site’s staff, but it’s still important for invited people to know to avoid moral hazard.
https://meta.discourse.org/t/invite-friends-functionality/6078/11

Maybe point 5 is indeed a bit much

[sam (Sam Saffron)]

@techAPJ can you add 1) and 2) to your list.

I think all of the list above is a good set of changes, 1 and 2 seem very simple and unquestionably good change.

[techAPJ (Arpit Jalan)]

Invitees shouldn’t have to confirm email address. The only way they got to the forum was reading an undisclosed token in their email.

I believe this has been fixed since after you posted this topic. I just tested the workflow and I was logged in directly without needing to confirm my email.

---

email_domains_blacklist should be used to validate invite emails. The inviter should know that email cannot be used.

Implemented:

FIX: invite email should be verified against `email_domains_blacklist`

---

We could create a notification when creating invitee accounts to instruct them to define username and password before leaving. That could avoid some confusion later on, when they try to login again.

On it!

---

The inviter could provide the invitee name when creating an invite. Starting the email with the inviter’s name may increase the likelihood of the invitees opening the email.

This can be done now by using Disposable Invite Tokens:

Generating lots of Invite Tokens

So you want to generate multiple Invite Tokens? Great! Let’s get started! Install discourse-invite-tokens plugin Plugin location: Installation instructions: Enable plugin After installing plugin enable site setting invite tokens enabled. Clone Discourse API Gem If you already have Git and Ruby installed on your system, you can install Discourse API by running following command from console: git clone https://github.com/discourse/discourse_api.git ~/discourse_api Generate Master API Key …

---

Use the inviter name instead of username in the email template and address. Invitees may not recognize the inviters username.

Implemented via:

Improve invite email copy

---

The private message(Welcome message) sent when the invitee accepts the invitation could be signed by the inviter, instead of the system. Aside from being more personal, the invitee is readily presented with the inviters account, making it easier for them to begin conversations inside discourse.

Not sure if this is the correct approach. Any feedback here @codinghorror.

[codinghorror (Jeff Atwood)]

We could create a notification when creating invitee accounts to instruct them to define username and password

This already exists @techapj they get a PM explaining this to them.

[codinghorror (Jeff Atwood)]

@angelim you should try this again – I just got invited to a Discourse site by @sam and the process was very smooth.

Also @techapj can you confirm that the email blacklist (point #2 in the list) is respected by the invite process, just to be sure?

[techAPJ (Arpit Jalan)]

@codinghorror

Also @techapj can you confirm that the email blacklist (point #2 in the list) is respected by the invite process, just to be sure?

Just tested locally, can confirm that email_domains_blacklist is verified in Invite process.

[sam (Sam Saffron)]

I think we are done with all of the changes and have a much improved invite workflow! @angelim thanks for originally raising this way back when!