Disabling activation email requirement for invited users

dev
1

Hi guys, I have a use case that’s currently not that well supported: I need to disable the activation email for invited users—including users who are invited with a link.

After I started the above topic this was implemented, but only for users invited via email.

My Discourse instance is invite-only and I am actually sending invite links via email, but not the built-in Discourse emails. I generate the invite links with a POST request to /invites/link and store them in an external DB, and from there I send the links to the user. So when users click the link they have in fact already verified their email, but are then asked to do it once more.

I realize my use case isn’t particularly common, so I figured I’d try to build a simple plugin to modify the required parts of Discourse to get this working the way I need it to.

I’ve got a skeleton up and running, and added a site setting (no_activation_enabled). After searching through the core repo I guess this might be the file that needs editing:

I’m not entirely sure, but I think maybe by conditionally (if SiteSetting.no_activation_enabled and if the user was invited by staff, perhaps invite.invited_by.staff?) changing active to true in the user.attributes could work:

    user.attributes = {
      email: invite.email,
      username: available_username,
      name: name || available_username,
      active: false,
      trust_level: SiteSetting.default_invitee_trust_level,
      ip_address: ip_address,
      registration_ip_address: ip_address
    }

But how do I go about changing this from a plugin? Is that even within the scope of what plugins can do? Or can they only add things, not modify them? Or do I need to replace the entire invite_redeemer.rb file?

I completed the introduction to plugin building, as well as this guide, but after hours trying to dig through the code base including other plugins, I feel like I’m banging my head against a wall… So if anyone has any pointers for me, I’d be super grateful!

3 Likes
2

If you’re handling this from an external site why not have it handle SSO and just pass the verification across in the payload?

2 Likes
3

Hi Stephen, thanks for your input.

I don’t handle user accounts on an external site. I have a master Airtable + Zapier + GCFs that connect together several services (ESPs, etc), but Discourse is the main user database. I just don’t want to use the regular Discourse signup form as it’s not great for conversions and can’t be integrated in e.g. blog posts. If anything Discourse is the SSO provider for the Jekyll-based content site as it sends fetch requests to see if a user is logged in on Discourse and adjusts the content pages based on that.

4

Hey, welcome :slight_smile:

Like @Stephen, I’m not entirely sure this is the right tool, but I trust you’ve thought it through sufficiently.

I would avoid this at all costs. There’s almost always another solution, even if you have to monkey patch a class. On monkey patching in Discourse see: Tips for overriding existing Discourse methods in plugins.

In this case it seems as though there’s already code in the method you’re focusing on that does what you’re after: https://github.com/discourse/discourse/blob/master/app/models/invite_redeemer.rb#L66

The issue is that the invites you’ve generated don’t have the right emailed_status_type, so that condition isn’t passing. I think the solution here is to generate different invites in the first place. That’s where I would focus.

2 Likes
5

This is essentially reintroducing a feature that was removed from core because it was too dangerous - if you ever mishandle these invitation tokens, whoever stole them (before the intended recipient uses them) could sign into the forum as the recipients. I highly suggest not using this style of invite for any moderator or admin accounts.

That’s why the code to handle this is already there, but you’ll need some custom fiddling to actually reach it.

3 Likes