# Una forma para que los administradores editen los IDs externos de los usuarios

**URL:** https://meta.discourse.org/t/a-way-for-admins-to-edit-users-external-ids/96976
**Category:** Feature
**Created:** [11 Septiembre, 2018 19:06 UTC](https://meta.discourse.org/t/a-way-for-admins-to-edit-users-external-ids/96976 "2018-09-11T19:06:40Z")
**Posts on this page:** 11
**Page:** 1

<div class="post-metadata">

### Author: ![sudoman](https://avatars.discourse-cdn.com/v4/letter/s/8baadc/32.png) [@sudoman](https://meta.discourse.org/u/sudoman)
#### Post date: [11 Septiembre, 2018 19:06 UTC](https://meta.discourse.org/t/a-way-for-admins-to-edit-users-external-ids/96976/1 "2018-09-11T19:06:40Z")

</div>

Hello Discourse,

Sometimes people request that we change their SSO user name. With some services, it’s possible to change users’ external IDs so that they can continue using the same accounts on other sites. Would you be interested in adding this feature to the site, or should we devise an SQL query to change this in Discourse’s DB?

Thanks,  
Andrew

---

<div class="post-metadata">

### Author: ![sudoman](https://avatars.discourse-cdn.com/v4/letter/s/8baadc/32.png) [@sudoman](https://meta.discourse.org/u/sudoman)
#### Post date: [11 Septiembre, 2018 19:09 UTC](https://meta.discourse.org/t/a-way-for-admins-to-edit-users-external-ids/96976/2 "2018-09-11T19:09:47Z")

</div>

Being able to change users’ email addresses too should help with collisions if an old account has an email address they would like to use on their new account. I know that this second request is more of an edge case, but it could be useful.

---

<div class="post-metadata">

### Author: ![sudoman](https://avatars.discourse-cdn.com/v4/letter/s/8baadc/32.png) [@sudoman](https://meta.discourse.org/u/sudoman)
#### Post date: [17 Octubre, 2018 16:47 UTC](https://meta.discourse.org/t/a-way-for-admins-to-edit-users-external-ids/96976/3 "2018-10-17T16:47:18Z")

</div>

I have a clarification about this issue, and a question about a work around.

By changing a user’s SSO name, what I mean is that sometimes people want their user name to be changed in our upstream CAS SSO server. This is easy for us to do, and we are then able to change external IDs on services that are clients to that CAS server. That means that users can still log into their old accounts with their new user name. It would be great if admins could update users’ External IDs in Discourse. Without this feature, we generally can’t change the user names of active forum users.

As a workaround, is there a way to change ownership of all posts written by a user? I suspect that would not be ideal, because there is a lot of additional metadata that can’t be transferred, like statistics and badges.

Thanks! 🙂

---

<div class="post-metadata">

### Author: ![sam](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/sam/32/102149_2.png) [@sam](https://meta.discourse.org/u/sam)
#### Post date: [17 Octubre, 2018 23:21 UTC](https://meta.discourse.org/t/a-way-for-admins-to-edit-users-external-ids/96976/4 "2018-10-17T23:21:00Z")

</div>

Can you use the sync\_sso endpoint, essentially that allows you to push any payload you wish via the SSO chain?

---

<div class="post-metadata">

### Author: ![sudoman](https://avatars.discourse-cdn.com/v4/letter/s/8baadc/32.png) [@sudoman](https://meta.discourse.org/u/sudoman)
#### Post date: [22 Octubre, 2018 15:33 UTC](https://meta.discourse.org/t/a-way-for-admins-to-edit-users-external-ids/96976/5 "2018-10-22T15:33:52Z")

</div>

is `sync_sso` part of the normal authentication procedure? If so, then I suspect that providing a SSO payload with the new name would simply create a new account with that External ID.

I grepped for `sync_sso` in the Discourse CAS SSO service source code and there were no matches. I looked through the Discourse repo, but I’m not sure how to use that function, which appear to be accessible via `/users/sync_sso`.

Thanks for your help.

---

<div class="post-metadata">

### Author: ![Falco](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/falco/32/179432_2.png) [@Falco](https://meta.discourse.org/u/Falco)
#### Post date: [22 Octubre, 2018 15:41 UTC](https://meta.discourse.org/t/a-way-for-admins-to-edit-users-external-ids/96976/6 "2018-10-22T15:41:56Z")

</div>

> [@sudoman](#):
>
> is `sync_sso` part of the normal authentication procedure?

Yes. That is a normal route for our official SSO system.

Everytime a user login happens the data from SSO syncs with Discourse. If you need the sync to happen outside logins, you can call `sync_sso` anytime you need.

> [@sudoman](#):
>
> I suspect that providing a SSO payload with the new name would simply create a new account with that External ID.

A new name with the same `external_id` should update the name of the user with that `external_id` if ` sso overrides username` is true.

> [@sudoman](#):
>
> I grepped for `sync_sso` in the Discourse CAS SSO

The CAS SSO is an unofficial plugin, and we don’t have experience with it.

---

<div class="post-metadata">

### Author: ![sudoman](https://avatars.discourse-cdn.com/v4/letter/s/8baadc/32.png) [@sudoman](https://meta.discourse.org/u/sudoman)
#### Post date: [22 Octubre, 2018 16:02 UTC](https://meta.discourse.org/t/a-way-for-admins-to-edit-users-external-ids/96976/7 "2018-10-22T16:02:51Z")

</div>

> [@Falco](#):
>
> A new name with the same `external_id` should update the name of the user with that `external_id` if `sso overrides username` is true.

That makes sense. However the issue here isn’t updating the user name of someone who logs in with an External ID of ‘bob’, but allowing Bob to log into the same account with the a new External ID of ‘alice’. In order to do so, it looks like the External ID of Bob’s account needs to be changed from ‘bob’ to ‘alice’.

If `sso_sync` is the way to go, would I simply need to craft a JSON payload and pass it to that URL? I think that this use case is common enough that having a guide or some pointers would be super helpful. Maybe I just need to read up on how to create a custom SSO service? Thanks!

---

<div class="post-metadata">

### Author: ![Falco](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/falco/32/179432_2.png) [@Falco](https://meta.discourse.org/u/Falco)
#### Post date: [22 Octubre, 2018 16:07 UTC](https://meta.discourse.org/t/a-way-for-admins-to-edit-users-external-ids/96976/8 "2018-10-22T16:07:04Z")

</div>

> [@sudoman](#):
>
> However the issue here isn’t updating the user name of someone who logs in with an External ID of ‘bob’, but allowing Bob to log into the same account with the a new External ID of ‘alice’. In order to do so, it looks like the External ID of Bob’s account needs to be changed from ‘bob’ to ‘alice’.

Why are you updating the `external_id`? The `external_id` is supposed to be a immutable identifier of the user in the auth source, like the ID column from the database or a long UUID, or anything stable.

From the documentation:

> [@Setup DiscourseConnect - Official Single-Sign-On for Discourse (sso)](https://meta.discourse.org/t/setup-discourseconnect-official-single-sign-on-for-discourse-sso/13045/1):
>
> **external\_id** is any string unique to the user that will never change, even if their email, name, etc change. The suggested value is your database’s ‘id’ row number.

---

<div class="post-metadata">

### Author: ![barryvan](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/barryvan/32/82635_2.png) [@barryvan](https://meta.discourse.org/u/barryvan)
#### Post date: [24 Febrero, 2019 23:58 UTC](https://meta.discourse.org/t/a-way-for-admins-to-edit-users-external-ids/96976/9 "2019-02-24T23:58:47Z")

</div>

I’ve just encountered a situation where I think changing the external ID is legitimate. One of our users has moved from one school to another, and when they did this, they were assigned a new account – with a new UUID and email address. They’ve since started using this account to connect with other third-party applications.

They then realised that they could no longer access their account on our Discourse instance – they had a new user created.

_At this point, I should have got in touch with the Discourse team to merge the accounts, but I thought I might be able to get away without doing so…_

I updated their email address on the _old_ account so that it matches their new email address – but they’re unable to log in because the external ID they’re using doesn’t match that account, and a new account can’t be created because the email address is in use. If I could simply edit their external ID, it would mean they could carry on quite happily.

I understand why there would be concerns around making a “merge user” function easily accessible from the admin interface; my feeling is that being able to edit the external ID for a user would likely mean that many merges aren’t necessary.

(As it stands, I’m seeing if I can change the UUID in _our_ system for this user, but if they’ve used it to access other third-party systems, I’ll end up having to ask the Discourse team to help me out… 😉)

---

<div class="post-metadata">

### Author: ![supermathie](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/supermathie/32/507518_2.png) [@supermathie](https://meta.discourse.org/u/supermathie)
#### Post date: [25 Febrero, 2019 00:14 UTC](https://meta.discourse.org/t/a-way-for-admins-to-edit-users-external-ids/96976/10 "2019-02-25T00:14:51Z")

</div>

You are correct!

From every point of view this is a different user, it just happens to be the same person operating the new account.

We’re happy to help you with this, just PM `@team` the details of which user needs their external ID wiped or usernames to merge.

---

<div class="post-metadata">

### Author: ![barryvan](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/barryvan/32/82635_2.png) [@barryvan](https://meta.discourse.org/u/barryvan)
#### Post date: [25 Febrero, 2019 00:48 UTC](https://meta.discourse.org/t/a-way-for-admins-to-edit-users-external-ids/96976/11 "2019-02-25T00:48:09Z")

</div>

Thanks @supermathie! I managed to sort this one by changing the UUID on our side (thankfully the user hadn’t yet made use of this UUID for other apps!), so all’s good for now. 🙂
