I’m getting situations where people need to change their email address but can’t get into Discourse to do it themselves, and are asking me, the admin, to do it for them. But I can’t see any way to do that, and so now I’ve got people who can’t get into the site. Is there a way for me to change a user’s email address?
I figured it out, enough to solve my immediate problem anyway.
I’m not sure it’s the best way to solve it, but if I impersonate the user, I can then change the address. I think an admin should probably have this ability, but it doesn’t come up that much, so I can live with this for now.
FYI:This was also recently discussed in a similar topic here although not 100% specific to your question:
Hmm, that thread does show a better way to do it. But why would it make sense to allow an admin to edit the user’s email address from the user’s preferences page (/users/{user}/preferences
), but not the admin page for the same user (/admin/users/{user}
). Surely the permissions should be the same on both?
However, this is still very helpful, thanks.
Slightly off-topic, But I’m curious.
As email address is the primary way of establishing a member’s identity, how is one able to know that “member A” is not trying to get at “member B’s” account?
I guess the admin would have to use his/her discretion. In this case, the user was abc@domain.com
, and the entry in the db was {SPACE}abc@domain.com
, and that leading space apparently matters. So it was pretty clear that I just needed to delete the space and fix an obvious typo.
Also, Discourse should probably trim leading and trailing whitespace, to prevent this obvious mistake.
How did that leading space get in there? Did the user enter it?
Actually the user was created via a script calling the /users
endpoint in the API, with data entered by the user, so really it’s a validation bug in my script, but probably the API should protect against this as well.
You are probably right given the importance of email. @techAPJ can you make sure the API guards against (strips) extra leading or trailing spaces when entering emails? Perhaps it could be part of the validation steps somehow.
Just pushed a fix:
To come back to the original question, I am trying to achieve the same thing: change a user email. However I am trying to do this via the API.
Looking at the documentation it seems possible via: users/:username/preferences/email
However looking at Discourse code it seems that this will trigger a job to send a confirmation email to the user. Is there a way to change a user email without the user confirmation?
Even if it’s a hacky way, I REALLY need to do it and I would like to avoid changing the value directly in the DB…
That is very risky unless you know with 100% certainty that the email is valid, which implies SSO.
Sometimes I know the email is valid because the user emailed from that address to ask me to change it for them in the system.
What I am trying to do is disabling a user and then give the opportunity for this same user to create another account with the same email address. That’s why I need to change/invalidate a user email address.
I know it does not sound like a regular usage of Discourse, just sharing it so that you guys have more context and you might have a different idea on how to achieve this.
I assume they are going to use a different username too? Why not just anonymize the account?
That indeed works! Thank you @cpradio
Hi,
Im trying all of the above but im simply not getting the edit pencil come up for changing the email address.
Im using SSO to sign users into discourse and have set email to be editable. Any other config that i maybe missing?
You need to edit the email at the SSO provider, or disable “sso overrides email” to let everyone change their own.
hmm, right, so i cant have SSO and edit ability together at the same time.
I do not want to disable SSO, but want to facilitate for the scenario when admin may have to manually change a users email address via the dashboard.
So my option is to temporarily switch off SSO, make the change and then switch it back on?
I guess the impersonate option being spoken of above will also only work with SSO off?
Or i would have to make the change in the database directly.
No, don’t disable SSO entirely - disable the sso overrides email
setting.