One way of making progress here is producing complete and comprehensive UI mock ups for the entire system proposed
4 Likes
Sounds good - Iāll see what I can do on this.
I discussed our plans above which we are starting to move forward on.
As one of the many users @downey was referring to, Iād love to see something like this in my Discourse preferences:
In our case, email addresses are not editable in Discourse, since theyāre provided by SSO. If we werenāt using SSO, then editing alternate emails could be done via a text area with one address per line.
For us, the primary need is to accept new posts via email from alternate email addresses, so users donāt need to worry about which account theyāre using to email the community.
11 Likes
Has there been any progress on this feature request? We are having several uses that email in requests form multiple addresses and get frustrated having to switch accounts all the time.
4 Likes
Regarding this use case:
What should happen after youāve sent a new reply in with your non-primary email address? Should that email also be subscribed to the thread now? As far as I can tell, that would get messy.
My suggestion would be that whenever you send in a new post using your non-primary email, you get a confirmation email back from Discourse saying:
Your post, sent from jane-social@example.com has been received and published. Please note however that you will only receive updates on your primary email, which is listed as jane@example.com.
8 Likes
[quote=āerlend_sh, post:26, topic:16328ā]
My suggestion would be that whenever you send in a new post using your non-primary email, you get a confirmation email back from Discourse[/quote]
I like it! 
Thanks for waking up this topic - itās not a huge issue for our community but does come up from time to time.
1 Like
If you wanted to send a reply to the alternate email address the first time it is used as a heads up, thatād be okay. But, Iād think a reply every time I used my alternate email address would be more annoying than helpful. Also, maybe avoid promising the post has been published (e.g., it might be held for moderation or sitting in a spam queue):
Your post, sent from jane-social@example.com has been received and will be treated as if it came from your primary email, which is listed as jane@example.com. Any future posts from this address will be treated the same. Please note however that you will only receive updates on your primary email.
The ultimate approach would hold onto declined emails for a day, supporting a workflow like (1) Bob emails a post, (2) a "post declined. we donāt know you. if youāre using an alternate email you can add it here, (3) Bob clicks the link & adds his alternate email address, (4) Discourse says ādo you want to post the message you just sent from that address?ā and Bob says yes.
But Iād be happy just to be able to include alternate emails in my profile and have Discourse treat any messages from those addresses as if they came from my primary email.
5 Likes
This has also become a requirement for us, also to make it easier for users to reply to notifications/start threads without remembering which email address they have to send from as has been discussed before, but mostly to allow users to log-in with whatever service they want, and almost certainly end up logged into their account.
Definitely, I think the most use this feature would get in our instance is from employees who have a ātrueā email in the auth system (such as lmcardle@mo.co) but also an alias they use everywhere (such as leo@mo.co). Making users not have to remember which their primary on Discourse is, and not annoying them about having sent an email from the āwrongā address, would be very benefitial for us.
The one area which I havenāt seen any discussion around is around merging multiple accounts owned by the same user. It would be great to, after a user has verified they own an address they want to add as a secondary email, but before that address is actually added as a secondary email, check if any accounts exist with that email, and if they do, prompt the user asking if they want to change the owner of any posts owned by that user to themselves, and add all post/category notification levels from the other user. If they accept, Discourse would go ahead and make the ownership and notification level changes, delete the other account, and add the secondary email. If they decline, Discourse informs the user it canāt add the secondary email.
It would also be useful if this merging function could be easily called from a plugin, since for us the addition of secondary emails is going to be done automatically through our auth system.
4 Likes
Hello,
Iām new to discourse.
The idea seems pretty useful. I didnāt understand this:
It would also be useful if this merging function could be easily called from a plugin, since for us the addition of secondary emails is going to be done automatically through our auth system.
The system we use (and just for clarity here, when I say āweā, I donāt mean Meta Discourse, but Mozillaās Discourse instance) for logging users in will soon return multiple email addresses for each user to Discourse, and so there might be a need to merge users after a user logs in, if weāre trying to add a secondary email which already exists as a primary email for another user. This merge would have to be called from the code of the login plugin we use, and so programming the code which merges users in a way which can be easily executed from that plugin would be useful.
2 Likes
Longer term I am defninitely interested in supporting more than 1 validated email for each user account. Just not sure when we can get to it. How much work do you think this would be @sam as a baseline?
5 Likes
A couple of days for the server side of things, a couple more days for UI
3 Likes
Are we supporting 2 or {n} emails per user for that amount of work?
There are just lots of flows, reset password, social logins and user page and admin user page
I would only recommend adding backup email support, not N email support
3 Likes
Our requirement would be N email support. Iām interested in why you recommend adding only backup email support - N would be more work, but not a ridiculous amount more, no?
So if I get there first, would this be #pr-welcome?
3 Likes
My issue with N email support is that this is done pretty much nowhere and is not something that is easy to explain to users
Gmail, yahoo and Github only support a single backup email.
Also, conceptually, backup is about having a ājust in caseā email. All notifications and so on go to primary
2 Likes
The reason I see for N email support, in addition to being a backup, would be to support additional from addresses for email-in.
1 Like
I think weāre all generally in favour of N email support, but the implications of supporting more than a single backup email are not immediately clear.
This is one of those arguments that is best resolved with code. Simply:
-
Do a PR for 1 backup email, which you know will get accepted without much ado (and with much
) -
then we can resume the topic of N emails. If need be, do some basic mockups of how thisād work in Discourse (GitHub seems to provide a good frame of reference) before submitting a PR that adds N emails support.
1 Like