A new options setting called invite_code was added.
When set, all accounts being registered must enter the invite code in order to be allowed account creation. Users without this code are not allowed to register an account.
That requires manual moderation of each account. This setting is really very useful for those looking to test out with a few users or those running some kind of promo with forum access being a perk. Such an invite code will almost dramatically reduce work loads for pilot project forums as well.
Because I need to approve every single email and sit on the approval queue 24x7 and I donāt have any idea if this is a random bot that registered is really someone that should have access or not.
With an invite code I know that at least they had an invite code that I shared privately.
+1 for this feature, which is hugely useful for a number of communities I run. I get @codinghorror@ondrej point about manual approval above, but I think this fills a gap which exists between manually inviting everyone (āinvite onlyā site) and manually approving everyone (āapproveā users site).
We donāt want to approve users. We just want to post a code in a slack/telegram/whatsapp group and let everyone use it. Sometimes, a few extra testers before formal launch doesnāt hurt much.
I also find this very useful, especially if the functionality is slightly extended so that it becomes possible to āattachā groups to a specific invite code, i.e. someone creating an account using a specific code is automatically added to a specific group.
In some use cases, this might also solve the request for email independent invite tokens that comes up from time to timeā¦
There are two form of this that I am super happy to support
Please visit amazing.forum.com and enter the invite code: fantastic to gain access (implemented)
And
Please visit amazing.forum.com/register?code=fantastic to register and gain access to the forum
We have probably passed a rule of 100 here given our general way of solving this problem is placing sites behind HTTP basic auth.
Both are quite similar, I implement #1 for now but will follow up with #2.
#1 has the advantage that it is a bit easier when you are not relying on cut-and-paste, eg get instructions over whatsapp and then use the desktop to complete.
#2 has the advantage that it reduces typing in fantastic and is handy for an āemailā share vs a whatsapp share.
Not following where forum.this-magic-domain.org came from here? In both cases this is exactly the same domain the forum is on.
Hereās a quick mock of what I thought the UI was going to look like for this:
(This is on a dev site with must_approve_users on, after email validation)
It should be optional at signup and optional at login-while-not-approved, because anything that mandates all users manage to copy the code around is going to break & need admin intervention.
I realize now I just accidentally reiterated @codinghorrorās points from the previous topic. (which I had not read at time of writing, due to this being in #feature:announcements )
Essentially, this should be building on top of must_approve_users + login_required instead of making an entirely parallel system. The current implementation is fine as a hack to get us through the current crisis, but should be fixed up.
Someoneās going to forget the code or not write it down if you present it at a conference. Or you need to cycle the code after the conf videos go up. Itās a lot better to ask in your whatsapp group āwhose account is @test3?ā, get an affirmative response, and click
instead of trying to coax them through copying the code into the signup form correctly. (note: these screenshots are after email validation.)
I think itās fine, we just need to get to the eventual tweaks. There are definitely some improvements I fully support here.
First, integration with the user invites page, e.g. if you sign up on meta via visiting the link https://meta.discourse.org/signup?u=codinghorror then you show up as someone I invited on my user profile page, like so:
Remember that email based invites already grant TL1 to those users you invitedā¦ so we already have that perkā¦ check out the invite dialogā¦ notice you can add group access, too, and the TL bump is implicit. We should probably spell this out in the copy here on this dialog, actually:
Second, you should be able to generate invite links with no email from the same place you send invites, per the above ā¦ this completely resolves the ābut I donāt know their email addresses ā problem.
Third, I think itās fine for a site to be āinvite onlyā and the invites are all in the form of hyperlinks plus a secret password. That way itās
something you have (e.g. a link to a site)
something you know (e.g. the password open sesame)
And if your site has approvals, then the secret password lets you skip approval too. If you donāt have approvals, you canāt get in without the secret passwordā¦
My main issue is that weāre not integrating with the existing features here, rather bolting on some random stuff through an obscure site setting. But we can integrate, to make the invite feature even better rather than a weird standalone site setting.
ā¦ this completely resolves the ābut I donāt know their email addresses 
ā problem.