### Author:  [@tkrunning](https://meta.discourse.org/u/tkrunning)
#### Post date: [May 25, 2020, 4:21pm UTC](https://meta.discourse.org/t/disabling-activation-email-requirement-for-invited-users/152633/1 "2020-05-25T16:21:12Z")
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** _.
> [@Allow disabling activation email for invited users](https://meta.discourse.org/t/allow-disabling-activation-email-for-invited-users/88426):
>
> I’ve seen this [discussed briefly before](https://meta.discourse.org/t/disable-confirm-your-new-account-activation-email-for-invitees/68859), but I’d like to cast a vote for an option to turn off activation emails for users who were already invited. They already clicked the invitation link (which presumably was sent to their email), so there’s no need to ask them to confirm it again. I am aware that there might be cases where an invite link is generated and not sent via email, so perhaps it would be good to pass a variable to set activation as needed or not when a link is generated? What do …
After I started the above topic this was [implemented](https://github.com/discourse/discourse/commit/7977b09025751973f7ae1271f68aaab2716e01fa), 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:
```plaintext
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](https://meta.discourse.org/t/how-to-start-building-stuff-for-discourse-if-youre-newbie-like-myself/45954), 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!
---
### Author:  [@Stephen](https://meta.discourse.org/u/Stephen)
#### Post date: [May 25, 2020, 4:31pm UTC](https://meta.discourse.org/t/disabling-activation-email-requirement-for-invited-users/152633/2 "2020-05-25T16:31:36Z")
If you’re handling this from an external site why not have it handle SSO and just pass the verification across in the payload?
---
### Author:  [@tkrunning](https://meta.discourse.org/u/tkrunning)
#### Post date: [May 25, 2020, 9:55pm UTC](https://meta.discourse.org/t/disabling-activation-email-requirement-for-invited-users/152633/3 "2020-05-25T21:55:44Z")
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.
---
### Author:  [@angus](https://meta.discourse.org/u/angus)
#### Post date: [May 26, 2020, 12:30am UTC](https://meta.discourse.org/t/disabling-activation-email-requirement-for-invited-users/152633/4 "2020-05-26T00:30:27Z")
Hey, welcome 🙂
Like @Stephen, I’m not entirely sure this is the right tool, but I trust you’ve thought it through sufficiently.
> [@tkrunning](#):
>
> Or do I need to replace the entire `invite_redeemer.rb` file?
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: [Override existing Discourse methods in plugins](https://meta.discourse.org/t/tips-for-overriding-existing-discourse-methods-in-plugins/83389).
In this case it seems as though there’s already code in the method you’re focusing on that does what you’re after: [discourse/app/models/invite\_redeemer.rb at main · discourse/discourse · GitHub](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.
---
### Author:  [@riking](https://meta.discourse.org/u/riking)
#### Post date: [May 26, 2020, 5:00am UTC](https://meta.discourse.org/t/disabling-activation-email-requirement-for-invited-users/152633/5 "2020-05-26T05:00:38Z")
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.