@codinghorror, how about changing the email address for a member who is active? I don’t see a way to do that, and I have a couple members who want it.
Curiously, you can’t do this where you’d expect the admin for the user to be:
/admin/users/{user}
But you can do it at:
/users/{user}/preferences
In the UI, you can get here by viewing the user’s public profile, then choosing Preferences, and then the email address has an edit pencil next to it.
@emily2 is using SSO, so changing email is not really an option. What is your advice in the case of SSO @sam?
In case of SSO you just change it at the source, and set it to override emails. Then log off, log on and magic.
2 Likes
A post was merged into an existing topic: TuDiabetes SSO and changing email address
This works for members changing their own email address, but what about when an admin needs to jump in and change an email address on behalf of members?
We just bumped up against this problem on our wordpress/discourse SSO setup. There is no discourse interaction at all in this case, and the old email address remains in place.
Is there any way (hacky or otherwise) to have staff reliably change someone’s email address in both places with a minimum of hassle?
1 Like
We have run into this problem before as well, for example, with someone who did not regularly use the web site, and only used email incoming to post & reply. They had to go into their directory profile, update email address (with necessary validation steps) and then log back in to Discourse before they could send an email in from their new address.
1 Like
We are also encountering this bug, not with just SSO. The “email editable” flag overrides the admins ability to update addresses.
Been trying to find an answer for a while now. Changing to editable, impersonating as suggested elsewhere… all is bad and changing the SSO solution ad hoc to force a new email isn’t the way to do it…
(I actually forced the SSO database (i.e. not code) already to allow users to login but mails from Discourse still go out to the non-existent email)
Problem:
One user group had their domain go down
As an admin I cannot edit or impersonate so that I can replace people’s emails
Users are not on the level that they can understand any tech instructions so it’s manual work for me…
This has to have been solved by now? I probably cannot find a real solution?
2 Likes
Why isn’t that working for you @Peter_Backgren?
Needed some time to actually look at this and trying to figure it out. And to write up what I have tried and failed with.
I don’t understand what “changing it at the source” means. The SSO database already has a different email but it does not automatically propagate to Discourse when you log in. I actually published the code I’m using ages ago here:
https://meta.discourse.org/t/discourse-sso-external-site-provider-problems/32977/12
Somewhere in the middle where nonce is created, maybe there is some parameter I could add that would say “force_email_override=yes”.
But changing code for such a simple thing feels weird so I’ve tried the following using the site.
I’ve changed
“email editable - Allow users to change their e-mail address after registration.”
and that makes no difference.
So, I’ve tried letting an admin change the email (email editable both on and off).
There is no edit possibility next to Show. Showing it shows no edit. Looking at the public profile doesn’t show any way to edit it. Stumped 
.
I’ve tried impersonating… nope.
I’ve tried logging in as the user with “email editable” on and off. The user cannot edit the email either.
Running out of options to try… perhaps I need to run all the way via a command prompt and ./launcher to force the “email editable” to take effect?
Getting to the point when I’ve tried so many different approaches I probably have overlooked something basic by now…
1 Like
(been bug hunting a lot of different things lately, hence the late reply, sorry about that, I know task switching especially with bugs is inefficient)
When I looked at this earlier I figured I should be able to edit according to this.
Which means one of those settings (in the UI?) is not what I think it is?
Can I dump settings in a command prompt somehow? Like doing some
./launcher dump is_staff
I would especially expect administrator to be is_staff (haven’t tried as moderator).
1 Like
Ok, first of all, this is the only way I have managed to finally change the email of an user.
The culprit for me seemed to have been I provide the email in each sso authentication. I would then expect it to change in any subsequent login (since it works when a user gets registered for the first time I pretty much think the “&email=xxxx” part in the nonce (IIRC) should update it properly).
In the login setting the “sso overrides email” was on. So changes in the sso database should get reflected properly next time you log in? Logging off and logging in to force a new login has no effect.
But, once the “sso overrides email” is off, both the user and an admin can edit the email.
Hey presto! Hopefully this solves the problem for a few other people as well?
Makes sense, wonder why I missed that option earlier. Probably because I thought that exact option should handle it correctly.
So, is the “sso overrides email” the actual bug (apart from the process being overly complicated 
)?
Just reading the code it would seem so, sso emails do not propagate after the initial registration.
@sam, if needed I can give you the opened up sso details (uncoded message parts) but this is probably something that can be tested without me messing around any further.
1 Like
I had some trouble with this issue as well, but I don’t have good enough data to figure out what went wrong. We changed the user’s email at the source. I gave her a link to log out of Discourse (which also logs her out of the source system), just in case, and a link to login again in at the source using the new email.
She told me that she followed my instructions (and she did, from what I could tell based on her activity on Discourse), but her email address remained unchanged on Discourse. A few days later I checked Discourse again it was changed. I don’t know what caused the delay. Is there some cache I should clean when I know users have changed their emails?
Actually, when I re-opened the issue earlier today, I only found one user that had the old email. I thought I had more than one.
And looking backwards in this topic, one of the “bad” users was frbulllover and her address was now correct (11 days later).
So during some logins, the sso override seems to work. Since I have a link to the actual sso code in this topic as well one can see that the email is always given. Hmmmmm…
I have obviously logged in and out trying to fix this.
Could it be the 2 week login cookie has to expire before the sso override takes place??? A simple logout/login is not sufficient?
Does it work if you remotely log out the target user from /admin and then have them login again?
1 Like
Kicked out the user twice and both times the email changed correctly.
Maybe not a cookie then. Or maybe things just work the way they are supposed now. I haven’t updated Discourse for a month though not to get a “fix” by mistake as I want to figure out the real reason for things not working.
The really weird part using the admin logout for a user is that it crashed the SSO solution (once). I don’t have any logout actions enabled! I’ve had this happen once before and it took me ages to figure out how to fix it (did the domain crash, etc). Basically the sso solution .NET 4.6 environment crashes and has to be restarted (using Lfchosting as my hosting environment and I have plenty of software there NOT crashing, ever). I’m seriously wondering whether kicking someone out and the subsequent automatic login via SSO happens several times in a row or in some weird manner differently from the normal authentication that then makes the .NET environment crash?
Every time things that make no sense happen I should of course check all logs, actually log in to discourse on the server and try to figure it out. I just don’t have time for this anymore today… need to get some work done.
2 Likes
Weird! The fact that force-logging out the user makes me think that he didn’t really log out before, so no SSO happened (he just kept on using his old session).
(I have no idea about the crashes, though.)
1 Like
I don’t have a real-world test case right now, but when it comes up again, I’ll let you know what happens.
1 Like