Invite workflow

Feature
1

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.
8 Likes
2

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 :thumbsup: 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.
3

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 :smile:

4

@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.

3 Likes
5

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.

Implemented:

On it! :racehorse:

This can be done now by using Disposable Invite Tokens:

Implemented via:

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

1 Like
6

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

2 Likes
7

@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?

1 Like
8

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

2 Likes
9

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!

4 Likes