Continuing the discussion from How to approve user secondary email from command line?:
On a more general question, we need an email-less instance of Discourse - i.e. such that it does not need to receive nor send any emails. Is this achievable?
Continuing the discussion from How to approve user secondary email from command line?:
On a more general question, we need an email-less instance of Discourse - i.e. such that it does not need to receive nor send any emails. Is this achievable?
I’m not sure if it meets your requirements, but it can be done with DiscourseConnect. Basically, just set a fake email addresses for the email field on the SSO record and set the site’s disable emails
setting to either “yes”, or (probably better) “non-staff”. Then setup a DiscourseConnect provider site that allows for registration without an email address.
If possible, it’s probably safer to have staff accounts have real email addresses and receive emails from the site. For example, that will allow them to login via the /u/admin-login
route if there’s ever an issue with DiscourseConnect.
The solution proposed sounds more like a workaround than a feature. Hence me selecting the feature category for my topic.
The idea is to have a truly email-less instance.
An example would be a protonmail account that you can setup without specifying any other email (except some cases when their verification system triggers a “need an additional verification” flag).
In our particular case, we would not want to use any 3rd party verification service. We don’t need any email notifications or reply-via-email; people would be super confortable interacting with the system through their browers (or in the mobile app) entirely. So, the thing that prevents us from having such a setup is the inability of the user registration to function without emails. Which is, well, a bit countrary to excpectations for some communities considering the amount of services that exist nowadays that don’t require any email at all.
Do you think it would be a viable feature request that has a chance to be implemented at some point in time in Discourse?
Ah, from my read it sounded more like a support question than a feature proposal.
There is this plugin that may be of some use:
I’m not sure how robust it is though.
Nice to know about them. But their roadmap is 20% complete, so I’m afraid to use it.
Hey, I’m still working on developing my plugin. It’s still in early stages and I wouldn’t recommend using it in production unless its a must for your community. Although let me know if you have any features you want me to prioritize and I can try to do that.