First suggestion is invite tracking only? Yeah, sure. Username w/o token shouldn’t grant TL1 because usernames are public info.
May I suggest that these links take the form of https://meta.discourse.org/signup?u=codinghorror&token=3ojk6WTY to mirror the first part 
didn’t think of that. Going to be tricky to document, but that’s how the settings should interact.
Yeah there’s no downside to copying Discord here. I think we had pure URL based invites (no email required) in the past but had to remove them due to security issues, do you remember @techapj? 
Yeah, the “no email required” part was the security mistake there - these invites should still require email validation (or social login w/ email validation), because they’re not landing directly in people’s email inboxes.
If the goal is to make this as easy to share, then what about approaching this like a referral code. Something that’s easily shared on a presentation deck, in plain text, or via word of mouth. Querystrings are confusing and fragile, whereas domainname.tld/invite/samgdc2020 is memorable and low risk, the kind of thing people can scribble down and survive in transit.
As a precautionary measure I would really love to see some form of code expiration as a layer of protection too.
Length of time and or number of uses would be a reasonable limit other software has implemented for this sort of thing. And it’s generally user defined.
Indeed but looking at the PR it’s a single code for the entire site.
Yes, we still have that feature around wrapped in a plugin:
The URL will be of the form: http://discourse.example.com/invite-token/redeem/TOKEN?username=USERNAME&email=EMAIL&name=NAME&topic=TOPICID
Bare minimum URL should be: http://discourse.example.com/invite-token/redeem/TOKEN?email=EMAIL
The security issue was that we did not check for the existence of user with the email address provided but now we do in the plugin.
I guess the username could be baked into the token be default and perhaps overwritten by adding an explicit user?
When it comes to token, I would prefer using code instead because it is comprehensible to non-technical people.
I believe not. While the tokens generated by the plugin don’t include emails, they can only be used by adding an email whereas here the idea is to remove that requirement, right?
And the security issue can be resolved:
This would be so awesome to have.
Do these invite codes ever expire or are they good indefinitely forever? We might want a hard limit here as a site setting at least for now?
Don’t we still need an email address for https://github.com/discourse/discourse-invite-tokens to work? It could be I misunderstand how it works.
What I’d like would be a tailored link (without an email address) that I could get organisations to send out to their punters, which would then assign them to a group and a starting topic when they sign up. The reason for this is that the medical organisations I deal with cannot / will not share their email list, but are happy to send an email to their members (from them).
I think both your request here and @nathank’s feature request are pretty related.
At the moment we have 1 global invite code, it has no expiry, to expire it the admin can just zero out the code or change it.
What is being asked here is a more sophisticated mechanism for invite codes where it is integrated into the global invite system.
The key features that are being asked for
New invite link
reusable N times
(optionally) automatically adds user to group
expires after M days
So this to me feels like an extension of this dialog:
Perhaps a tab there?
[bulk invite]Strip email
Strip send invite button
Add
How many people are allowed to register using this link?
How long would you like this invite link to work for? default 1 month.
So once you fill that up you would get an invite link that works for a limited time, integrates with the rest of the invite system, allows you to add people to groups and so on.
With that in place we can actually remove the whole “invite code” global feature.
Spot on - that would meet the need beautifully.
It would also be great to include a landing topic/post, as per the Bulk Invites via csv. Keeps it all consistent too.
If it is relevant to current global events I support prioritizing this work but it is your call to make @sam
No, invite-tokens does not need email address. See Generating lots of Invite Tokens to understand how it works.
I’ve read that, but remain confused.
This seems to imply very strongly that you need the user’s email. Or am I just being thick?
My understanding of bulk invite tokens is that you get one token per invite. This is very far away from what you are desiring here.
I will discuss this with @techAPJ I feel onboarding people efficiently to a new forum is very relevant and important in the current time. We are going to prioritize improving this story.
The email is required at the time of accepting invite but not at the time of invite token generation.
You can hand out this URL to end user and ask them to replace EMAIL with their email address: http://discourse.example.com/invite-token/redeem/TOKEN?email=EMAIL.
I hope this clears the confusion.
Very much liking your proposed solution in post 31 to this @sam, extending the functionality of invite codes.
Agreed that is also what I would really like to see implemented.
So that anyone that has access to the invite user permission is able to to generate a generic invite link that will let the user join and be added to the list of invited users of the referrer.
Invite to groups and with time/member limits would be nice but not a priority for me.
I’m getting a “Oops! That page doesn’t exist or is private.” when I try this.
amazing.forum.com/signup will pop up the signup modal, but amazing.forum.com/signup?code=fantastic doesn’t seem to pass the value into the modal (I also tried invite_code=fantastic).
And, when this works, it’d be nice to add it to the OP.