Invite workflow

(Alexandre Angelim) #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.
Should welcome message for invited users come from the inviter?
(Mittineague) #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.
(Alexandre Angelim) #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?source_topic_id=14460

Maybe point 5 is indeed a bit much :smile:

(Sam Saffron) #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.

(Arpit Jalan) #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.

(Jeff Atwood) #6

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

(Jeff Atwood) #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?

(Arpit Jalan) #8

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